Добро пожаловать в тред любви, взаимопомощи и делайте игры
Шапка: https://hipolink.me/godothread
Предыдущий 81: >>1092274 (OP)
---
Maintenance release: Godot 4.7.1: https://godotengine.org/article/maintenance-release-godot-4-7-1/
Все версии, скачать: https://github.com/godotengine/godot-builds/releases
Шапка: https://hipolink.me/godothread
Предыдущий 81: >>1092274 (OP)
---
Maintenance release: Godot 4.7.1: https://godotengine.org/article/maintenance-release-godot-4-7-1/
Все версии, скачать: https://github.com/godotengine/godot-builds/releases
>>097332 (OP)
Зачем на коробках говном намазали? Норм же пикча была. Какая-то прям уж чрезмерная шиза на движкосраче.
>пик1
Зачем на коробках говном намазали? Норм же пикча была. Какая-то прям уж чрезмерная шиза на движкосраче.
>>097332 (OP)
>>1097241 →
Это из-за несовместимости файловой системы Windows и Linux/Android. Если ты создашь файл MyScene.tscn и myscene.tscn, то в линуксе это будет 2 разных файла, а виндоус - одинаковый и какой-то из них перезапишет второй. И да, это выстреливало у людей в разных проектах, при скачивании аддона или при экспорте на телефон. Поэтому логичнее называть все в одном регистре, но тогда слова сливаются, поэтому добавляют подчеркивание my_scene.tscn
Да и в с++ такой стандарт, так что лучше сразу привыкать к хорошему.
>>1097241 →
Это из-за несовместимости файловой системы Windows и Linux/Android. Если ты создашь файл MyScene.tscn и myscene.tscn, то в линуксе это будет 2 разных файла, а виндоус - одинаковый и какой-то из них перезапишет второй. И да, это выстреливало у людей в разных проектах, при скачивании аддона или при экспорте на телефон. Поэтому логичнее называть все в одном регистре, но тогда слова сливаются, поэтому добавляют подчеркивание my_scene.tscn
Да и в с++ такой стандарт, так что лучше сразу привыкать к хорошему.
>>097359
Я это знаю, на практике никогда такого не случалось, если придерживаешься одного стиля (например у джавистов).
Как-будто проблема преувеличена.
То что можно случайно рекурсивно снести папку .gdignore со всеми сорцами - их не беспокоит, а проблема 1% процента линуксоидов, которые это знают с рождения на генетическом уровне - беспокоит
Кто полжизни жил с верблюдом (или паскалем), это может помочь, все равно все соло сидят.
>Это из-за несовместимости файловой системы
Я это знаю, на практике никогда такого не случалось, если придерживаешься одного стиля (например у джавистов).
Как-будто проблема преувеличена.
То что можно случайно рекурсивно снести папку .gdignore со всеми сорцами - их не беспокоит, а проблема 1% процента линуксоидов, которые это знают с рождения на генетическом уровне - беспокоит
Кто полжизни жил с верблюдом (или паскалем), это может помочь, все равно все соло сидят.
Сделал классный аддон и хотел залить в стор, а там стали требовать картинки на превью в 720п и чтобы красивые, всякие карусели и видео как работать с аддоном. Забил хуй. А аддон классный кстати!
>>097383
Я не умею рисовать. Хочется чтобы было симпатично, это легко. Я взял иконку и подписал ее названием аддона. А потом оказалось что надо ее очень большую делать и вообще красивую. Ну я и забил, мне лень этим заниматься. Старый ассет стор был в этом плане куда добрее.
Я не умею рисовать. Хочется чтобы было симпатично, это легко. Я взял иконку и подписал ее названием аддона. А потом оказалось что надо ее очень большую делать и вообще красивую. Ну я и забил, мне лень этим заниматься. Старый ассет стор был в этом плане куда добрее.
>>097384
Вот кто украл твою мотивацию.
https://store.godotengine.org/asset/godot-foundation/scene-changer-demo/
Вот кто украл твою мотивацию.
https://store.godotengine.org/asset/godot-foundation/scene-changer-demo/
>>097388
Я же написал что хочется чтобы было красиво. Сделать в пеинте картинку пустую дело нехитрое. Привлечет ли аддон этим внимание? Нет.
Я же написал что хочется чтобы было красиво. Сделать в пеинте картинку пустую дело нехитрое. Привлечет ли аддон этим внимание? Нет.
>>097332 (OP)
Опять кринжово-нейрослоповый перекат...
Тебе не надоело этот ШИЗО РИФТ пиарить?
>>1097230 →
Фу - это кринжово-слоповый арт всратстоуна.
Они слопили свои карточки ещё до нейросетей.
>>1097226 →
>>1097330 →
За код не беспокойся, ты забросишь из-за арта.
>>097379
Пруфов, я так понимаю, не будет?
>>097384
Я бы дал советы, но, по-моему, ты просто троллишь.
Опять кринжово-нейрослоповый перекат...
Тебе не надоело этот ШИЗО РИФТ пиарить?
>>1097230 →
>"фу..." (особенно после артов херстоуна)
Фу - это кринжово-слоповый арт всратстоуна.
Они слопили свои карточки ещё до нейросетей.
>>1097226 →
>Есть ли готовые кодовые базы
>>1097330 →
>есть локации, ты ходишь по ним
>находишь НПС/врагов/сюжетное
>сидишь напротив соперника
>ещё окружение будет решать
За код не беспокойся, ты забросишь из-за арта.
>>097379
>Сделал классный аддон... аддон классный кстати!
Пруфов, я так понимаю, не будет?
>>097384
>не умею рисовать. Хочется чтобы было симпатично
Я бы дал советы, но, по-моему, ты просто троллишь.
>>097390
Нихуя ты натолстил. Если бы на симпатичный дизайн внимания не обращали и на нормальное оформление, то дохуя каких продуктов бы не продались. Ты еще расскажи сказку что капсула в стиме не решает, ага.
>>097396
Ну на пруф. Аддон за тебя автоматом генерирует мапки пикрил 1 вида чтобы можно было потом удобно без ебли с уидами загружать ресурсы как например. Поменял путь ресурса с картинкой или звук - генератор за тебя маппинг пересоздаст и ты будешь уверен что твой меин меню или Sounds.Attack всегда один и тот же.
SignalManager.switch_ui_scene.emit(UIConsts.MAIN_MENU)
SignalManager.switch_ui_scene.connect(_on_switch_ui)
func _on_switch_ui(sceneUiName: StringName) -> void:
var new_ui_path: StringName = UIDMaps.UI_PATHS.get(sceneUiName, "")
var new_ui_resource: PackedScene = SceneLoaderManager.load_scene(new_ui_path)
var new_ui_node: Node = new_ui_resource.instantiate()
add_child(new_ui_node)
И твой охуительный совет небось будет "открой чатгпт и сгенерь лол)))"
Нихуя ты натолстил. Если бы на симпатичный дизайн внимания не обращали и на нормальное оформление, то дохуя каких продуктов бы не продались. Ты еще расскажи сказку что капсула в стиме не решает, ага.
>>097396
> Пруфов, я так понимаю, не будет?
Ну на пруф. Аддон за тебя автоматом генерирует мапки пикрил 1 вида чтобы можно было потом удобно без ебли с уидами загружать ресурсы как например. Поменял путь ресурса с картинкой или звук - генератор за тебя маппинг пересоздаст и ты будешь уверен что твой меин меню или Sounds.Attack всегда один и тот же.
SignalManager.switch_ui_scene.emit(UIConsts.MAIN_MENU)
SignalManager.switch_ui_scene.connect(_on_switch_ui)
func _on_switch_ui(sceneUiName: StringName) -> void:
var new_ui_path: StringName = UIDMaps.UI_PATHS.get(sceneUiName, "")
var new_ui_resource: PackedScene = SceneLoaderManager.load_scene(new_ui_path)
var new_ui_node: Node = new_ui_resource.instantiate()
add_child(new_ui_node)
И твой охуительный совет небось будет "открой чатгпт и сгенерь лол)))"
>>097379
Это еще что. Когда/если игру сделаешь, и начнешь публиковать ее, охуеешь сколько ассетов разных размеров и аспектов требуется. Плюс видосы еще. Сидишь нарезаешь как дурак. Я после энной игры уже не делаю готовые картинки, а имею отдельные слои каждого элемента картинки, чтобы потом, по требованию, накидать их по-быстрому и, например, не отпиливать персонажу половину головы. И так под каждый стор.
Это еще что. Когда/если игру сделаешь, и начнешь публиковать ее, охуеешь сколько ассетов разных размеров и аспектов требуется. Плюс видосы еще. Сидишь нарезаешь как дурак. Я после энной игры уже не делаю готовые картинки, а имею отдельные слои каждого элемента картинки, чтобы потом, по требованию, накидать их по-быстрому и, например, не отпиливать персонажу половину головы. И так под каждый стор.
>>097403
Когда сделаю тогда и пригоню как блинчик, все верно. Сейчас в процессе полировки демки. Ее пока думаю через итч погонять и потом залить в стим расширенную версию с новым уровнем и добавить в демо несколько ачивок.
Когда сделаю тогда и пригоню как блинчик, все верно. Сейчас в процессе полировки демки. Ее пока думаю через итч погонять и потом залить в стим расширенную версию с новым уровнем и добавить в демо несколько ачивок.
19 Кб, 548x101>>097399
Я не понял, ты реализовал механизм перетаскивание с UID неймингом?
Я выбираю только розовые аддоны, функционал мне не интересен
>Аддон за тебя автоматом генерирует мапки
Я не понял, ты реализовал механизм перетаскивание с UID неймингом?
>ты натолстил
Я выбираю только розовые аддоны, функционал мне не интересен
>>097407
Да, браток, я тоже помню что уид 57865336776pfsxxikbcdse это ссылка на сцену двери, я же в голове все их держу
Да, браток, я тоже помню что уид 57865336776pfsxxikbcdse это ссылка на сцену двери, я же в голове все их держу
>>097399
Извини, но это какой-то ненужный велосипед...
Не обвешивать свой проект лапшой типа:
Потом очень больно будет переделывать.
А что касается UID в скриптах - я ими не пользуюсь принципиально, разве что в грубом прототипе, что планируется выкинуть/удалить в тот же день. Для постоянного кода, который планируется в будущем использовать, где нужна надёжность, лучше так:
И пробросить нужные файлы в инспекторе.
Если нужна только ссылка на файл, тогда:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html#strings-as-paths
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-annotation-export-file
Извини, но это какой-то ненужный велосипед...
>И твой охуительный совет небось будет
Не обвешивать свой проект лапшой типа:
>SignalManager.switch_ui_scene.emit
Потом очень больно будет переделывать.
А что касается UID в скриптах - я ими не пользуюсь принципиально, разве что в грубом прототипе, что планируется выкинуть/удалить в тот же день. Для постоянного кода, который планируется в будущем использовать, где нужна надёжность, лучше так:
>@export var main_menu: PackedScene
>@export var pause_menu: PackedScene
>@export var settings_menu: PackedScene
И пробросить нужные файлы в инспекторе.
Если нужна только ссылка на файл, тогда:
>@export_file var main_menu_path: String
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html#strings-as-paths
https://docs.godotengine.org/en/stable/classes/class_%40gdscript.html#class-gdscript-annotation-export-file
>Note: The file will be stored and referenced as UID, if available. This ensures that the reference is valid even when the file is moved. You can use ResourceUID methods to convert it to path.
>>097396
О, красиво выглядящая 3д игра. Спасибо, что подсказал, а то я бы не обратил внимания.
>Тебе не надоело этот ШИЗО РИФТ пиарить?
О, красиво выглядящая 3д игра. Спасибо, что подсказал, а то я бы не обратил внимания.
>>097435
Скорее "симулятор ходьбы по комнатам с !!!КРУТЫМИ ШЕЙДЕРАМИ!!!"...
Как технодемо шейдеров в Godot - это круто, не спорю, но в чём там игра-то?
Самое главное, в своём проекте ты задолбаешься такое имплементировать...
>игра
Скорее "симулятор ходьбы по комнатам с !!!КРУТЫМИ ШЕЙДЕРАМИ!!!"...
Как технодемо шейдеров в Godot - это круто, не спорю, но в чём там игра-то?
Самое главное, в своём проекте ты задолбаешься такое имплементировать...
3 Кб, 59x42>>097437
А в моей игре давно подобное имплементировано. Окклюжн куллинг комнат, анимированные трансформации некоторых объектов окружения. Этим кайфово заниматься.
А в моей игре давно подобное имплементировано. Окклюжн куллинг комнат, анимированные трансформации некоторых объектов окружения. Этим кайфово заниматься.
>>097411
Мне до демки ещё месяца два. Там такая игра что для демки надо 90% механик сделать.
Мне до демки ещё месяца два. Там такая игра что для демки надо 90% механик сделать.
>>097409
Ого, я же так люблю лишний раз курсорами мыши водить, это же так удобно. Возможно - чисто возможно - была какая-то причина, по которой много кодовой базы запретили юзать var? Надеюсь что поиск ты тоже не через ctrl+f делаешь, а через панель сверху мышкой.
А вообще заебал жирнить, да.
>>097412
Круто, еще ламерские советы будут? Я так понимаю тебя ui напрямую с основным кодом связано, с удовольствием посмотрел бы на портянку состояний когда у тебя игрок связан с окном паузы. Твои системы должны быть настолько разделены, чтобы ты буквально мог скопировать папку ui и условную core в новый проект и они бы там завелись с полпинка. Пописал бы хоть разок в жизни ui на фронту или на винаппы - знал бы про паттерны как это все должно между собой общаться и жить, чтобы в будущем не было попоболи.
Походу чукча не очень читатель и не знает про проблемы экспорта. В целом мне все понятно, тут все ожидаемо было.
Ого, я же так люблю лишний раз курсорами мыши водить, это же так удобно. Возможно - чисто возможно - была какая-то причина, по которой много кодовой базы запретили юзать var? Надеюсь что поиск ты тоже не через ctrl+f делаешь, а через панель сверху мышкой.
А вообще заебал жирнить, да.
>>097412
> Не обвешивать свой проект лапшой типа:
Круто, еще ламерские советы будут? Я так понимаю тебя ui напрямую с основным кодом связано, с удовольствием посмотрел бы на портянку состояний когда у тебя игрок связан с окном паузы. Твои системы должны быть настолько разделены, чтобы ты буквально мог скопировать папку ui и условную core в новый проект и они бы там завелись с полпинка. Пописал бы хоть разок в жизни ui на фронту или на винаппы - знал бы про паттерны как это все должно между собой общаться и жить, чтобы в будущем не было попоболи.
> @export
Походу чукча не очень читатель и не знает про проблемы экспорта. В целом мне все понятно, тут все ожидаемо было.
>>097396
Обычно видосы с ним приносил я, а не ОП. И я поддерживаю решение пихнуть в шапку - так меньше тупых вопросов типа "умеет ли годот в 3д". Именно с этой целью и приношу.
Я бы вообще в каждый перекат по 3д игре пихал.
>Тебе не надоело этот ШИЗО РИФТ пиарить?
Обычно видосы с ним приносил я, а не ОП. И я поддерживаю решение пихнуть в шапку - так меньше тупых вопросов типа "умеет ли годот в 3д". Именно с этой целью и приношу.
Я бы вообще в каждый перекат по 3д игре пихал.
275 Кб, 1672x941>>097332 (OP)
Теряется смысл сидения на берегу реки, если по ней проплывают какие-то безымянные ящики. Годетта не для того на берегу реки сидела.
> censored.png
Теряется смысл сидения на берегу реки, если по ней проплывают какие-то безымянные ящики. Годетта не для того на берегу реки сидела.
>>097455
Этот шарит, ради чего сидят на берегу реки и ждут
Этот шарит, ради чего сидят на берегу реки и ждут
>>097451
Скопировал, а там:
Лады, настроил этот синглтон, а там:
ОК, попутал что-то, бывает, попробуем что-то другое:
WTF??? Придётся прочёсывать весь код и рефакторить его полностью...
Ну так поведай нам об этих Великих Проблемах Экспорта, ЧИТАТЕЛЬ.
>>097454
У таких сил не хватит на то, чтобы сделать игру: это ж гуглить надо!
>скопировать папку ui и условную core в новый проект
Скопировал, а там:
>Синглтон <синглтон> не синглтон, попробуйте синглтонить тоньше.
Лады, настроил этот синглтон, а там:
>Функция не функция, <синглтон> не тот синглтон, попробуйте другой.
ОК, попутал что-то, бывает, попробуем что-то другое:
>ERROR: ACCESS VIOLATION
WTF??? Придётся прочёсывать весь код и рефакторить его полностью...
>Походу чукча не очень читатель и не знает про проблемы экспорта
Ну так поведай нам об этих Великих Проблемах Экспорта, ЧИТАТЕЛЬ.
>>097454
>так меньше тупых вопросов типа "умеет ли годот в 3д"
У таких сил не хватит на то, чтобы сделать игру: это ж гуглить надо!
Для тех кто использует подход с сервисами/менеджерами (не важно почему), есть потребность исполнения кода перед первым _proccess (чтобы вся сцена загрузилась и все _ready/@onready отработали). Нашел более элегантное решение без корутин и await'ов
-------------------------------------------
func _ready():
...._start.call_deferred()
func _start():
....pass
-------------------------------------------
Если дернуть call_deferred в _ready она очередью отработает после всех _ready до первого _proccess. Пользуйтесь
-------------------------------------------
func _ready():
...._start.call_deferred()
func _start():
....pass
-------------------------------------------
Если дернуть call_deferred в _ready она очередью отработает после всех _ready до первого _proccess. Пользуйтесь
15 Кб, 325x274>>097451
Ну да, она же на соседнем столе. Вообще uid удобен для постоянного рефакторинга и перетаскивания. Если ты человек без мышки, то тебе и uid ненужон.
Забавно, но чаще почему-то нужен ctrl+shift+f (наверное, потому что есть список методов) или Ctrl + R анализируя твои вскрики, я делаю вывод, что эти хоткеи я узнал еще до твоего рождения
Я представляю как тебе больно, давайте скинемся и купим человеку мышку, пускай новыми фичами хоть попользуется.
Ппц у тебя бардак в голове.
Экспорт самая удобная форма uid.
Какой чепухой люди готовы заниматься чтобы не делать игры.
>Ого, я же так люблю лишний раз курсорами мыши водить, это же так удобно
Ну да, она же на соседнем столе. Вообще uid удобен для постоянного рефакторинга и перетаскивания. Если ты человек без мышки, то тебе и uid ненужон.
>Надеюсь что поиск ты тоже не через ctrl+f делаешь
Забавно, но чаще почему-то нужен ctrl+shift+f (наверное, потому что есть список методов) или Ctrl + R анализируя твои вскрики, я делаю вывод, что эти хоткеи я узнал еще до твоего рождения
>пик
Я представляю как тебе больно, давайте скинемся и купим человеку мышку, пускай новыми фичами хоть попользуется.
>Возможно - чисто возможно - была какая-то причина, по которой много кодовой базы запретили юзать var?
Ппц у тебя бардак в голове.
>и не знает про проблемы экспорта
Экспорт самая удобная форма uid.
Какой чепухой люди готовы заниматься чтобы не делать игры.
6 Кб, 381x166>>097473
Будем честны, когда мы создаем новый проект мы мержим или вообще копируем файл project.godot. Руками заново писать инпуты, группы и прочее настройки - такое себе. Вместе с этим залетают и синглтоны, а там и папка core с 80% кодом, который пора выкинуть.
Вообще, я заметил локатор Game.some_service довольно популярен. А локатор между сценами нужен по-любому, особенно на прототипах (ручной DI это звездец вообще)
>Синглтон <синглтон> не синглтон, попробуйте синглтонить тоньше.
Будем честны, когда мы создаем новый проект мы мержим или вообще копируем файл project.godot. Руками заново писать инпуты, группы и прочее настройки - такое себе. Вместе с этим залетают и синглтоны, а там и папка core с 80% кодом, который пора выкинуть.
Вообще, я заметил локатор Game.some_service довольно популярен. А локатор между сценами нужен по-любому, особенно на прототипах (ручной DI это звездец вообще)
>>097493
Кто мы, кто мы-то? У меня каждая игра в другом жанре в другом стиле с другой графикой и с другим управлением. Сейчас бы переносить все из пиксельного пошагового паззла в 3д гоночки.
Кто мы, кто мы-то? У меня каждая игра в другом жанре в другом стиле с другой графикой и с другим управлением. Сейчас бы переносить все из пиксельного пошагового паззла в 3д гоночки.
>>097454
Так все знают что не умеет и сделать демку на 10 секунд не равно в уметь
>вопросов типа "умеет ли годот в 3д"
Так все знают что не умеет и сделать демку на 10 секунд не равно в уметь
>>097539
Прост интересно как именно разные жанры делаются, какие особенности, подводные камни и все такое.
Прост интересно как именно разные жанры делаются, какие особенности, подводные камни и все такое.
Эх годот годот, не годоть меня! Не годоть меня, моего коня
5 Кб, 344x137Почему из коробки нет WaitGroup? или есть? Я что один пытаюсь не зависнуть на сигналах?
>>097590
Если кому надо (может ошибку найдет)
https://hastebin.com/share/reyocizavi.swift
Простая задача оказалась не очень простой из-за того что в сигналах может быть разное число аргументов.
Если кому надо (может ошибку найдет)
https://hastebin.com/share/reyocizavi.swift
Простая задача оказалась не очень простой из-за того что в сигналах может быть разное число аргументов.
>>097591
А зачем ты анбиндишь аргументы своей же _on_signal у которой нет аргументов? Не понял логику
>Простая задача оказалась не очень простой из-за того что в сигналах может быть разное число аргументов.
А зачем ты анбиндишь аргументы своей же _on_signal у которой нет аргументов? Не понял логику
>>097611
Понял, отмена
Понял, отмена
>>097611
Если сигнал передает аргумент, а у коллбэка его нет - вылетает ошибка. Я хз, можно ли сделать лучше.
Если сигнал передает аргумент, а у коллбэка его нет - вылетает ошибка. Я хз, можно ли сделать лучше.
>>097614
Они реально придумали костыль, вместо того чтобы всегда передавать один объект (в других языках - event). При этом еще назвали unbind, что звучит как противодействие bind.
Они реально придумали костыль, вместо того чтобы всегда передавать один объект (в других языках - event). При этом еще назвали unbind, что звучит как противодействие bind.
>>097614
Да, понял, логика чутка не сходится - аргумент анбиндится у коллбека
Можно вот так написать, не создавая лишний обьект без надобности:
Этот анбинд скорее всего сохраняется в объекте Callback и сигнал делат что-то типа
>Если сигнал передает аргумент, а у коллбэка его нет - вылетает ошибка.
Да, понял, логика чутка не сходится - аргумент анбиндится у коллбека
Можно вот так написать, не создавая лишний обьект без надобности:
>var callback: Callable = _on_signal
>что звучит как противодействие bind.
Этот анбинд скорее всего сохраняется в объекте Callback и сигнал делат что-то типа
> callback.bind(arg).unbind(callback.unbind_count).call()
>>097617
Аргумент unbind не абсолютный.
Ты передашь 3, потом 1 - в итоге у тебя будет висеть 2 (а не 1 как ожидал и это свалиться с ошибкой, потому что меньше можно, больше нельзя). С новыми объектами такой "памяти" нет.
Я хотел сказать отменяющий. В общем, обычно "bind" это что-то прикрепляют и открепляют. Я зол на то, что это херово гуглилось, а потом еще не очевидно понималось.
А в пошаговой херне без WaitGroup вообще тяжко (или я тупой, но точно я не хочу размазывать логику по сигналам)
>Можно вот так написать, не создавая лишний обьект без надобности:
>>var callback: Callable = _on_signal
Аргумент unbind не абсолютный.
Ты передашь 3, потом 1 - в итоге у тебя будет висеть 2 (а не 1 как ожидал и это свалиться с ошибкой, потому что меньше можно, больше нельзя). С новыми объектами такой "памяти" нет.
>что звучит как противодействие bind.
Я хотел сказать отменяющий. В общем, обычно "bind" это что-то прикрепляют и открепляют. Я зол на то, что это херово гуглилось, а потом еще не очевидно понималось.
А в пошаговой херне без WaitGroup вообще тяжко (или я тупой, но точно я не хочу размазывать логику по сигналам)
Быстрый урок по многопоточности
https://www.youtube.com/watch?v=4zmN3z5yUSM
https://www.youtube.com/watch?v=4zmN3z5yUSM
>>097635
На видео ни одной женщины.
На видео ни одной женщины.
>>097635
А ведь вместо конференции могли бы делать игры.
А ведь вместо конференции могли бы делать игры.
>>097539
[crying mode]
Забавно, когда видишь ячейко-ориентированную пошаговую игру - думаешь как легко такое можно сделать. А на деле же это ппц когда у тебя уже есть движок.
Ну например волк/медведь занимает уже два тайла, а тролль все четыре - ты уже думаешь в рамках body-коллайдеров, а не одного тайла.
Потом области и взаимодействие. Тебе надо с нуля писать квадратную арену и вычисления того кто туда попадает и кто выходит, а с учетом выше информации у тебя и сами объекты уже не точка в пространстве, а какой-то объем тайлов.
Так же перемещение, ты постепенно начинаешь используешь tween'ы чтобы имитировать импульс движения.
То есть, ты начинаешь писать свою физику, только единица вычисления у тебя ячейка 64х64. А писать свою физику - ну такое себе.
Сразу же появляется мысль - просто адаптировать коллайдеры под квадратные тайлы. Но тогда рушиться все. Вся простота дешевизна тайлового расчета, даже AStar начинает посасывать с навигацией (и уже хочется выкинуть его, а ты все еще в тайловой-перемещении). И я молчу про производительность.
Мне уже кажется что для кого-то 3д шутана - беги стреляй, кода будет на порядок меньше, чем для тайловой пошаговой игры, где тебе нужно все переизбирать (а я же не собираюсь писать свой движок, да?).
И вот ловишь кризис - а может ну его? И сделать просто реалтайм top-down RPG - добавить стрельбу, а чтобы не просрать дух средневековьея - засунуть пост-апокалипсис. Ведь стрельба лучше смотрится чем когда спрайты трутся близи. В общем, опять кризис почаны.
Думать, унижен, прокрастинация.
[crying mode]
Забавно, когда видишь ячейко-ориентированную пошаговую игру - думаешь как легко такое можно сделать. А на деле же это ппц когда у тебя уже есть движок.
Ну например волк/медведь занимает уже два тайла, а тролль все четыре - ты уже думаешь в рамках body-коллайдеров, а не одного тайла.
Потом области и взаимодействие. Тебе надо с нуля писать квадратную арену и вычисления того кто туда попадает и кто выходит, а с учетом выше информации у тебя и сами объекты уже не точка в пространстве, а какой-то объем тайлов.
Так же перемещение, ты постепенно начинаешь используешь tween'ы чтобы имитировать импульс движения.
То есть, ты начинаешь писать свою физику, только единица вычисления у тебя ячейка 64х64. А писать свою физику - ну такое себе.
Сразу же появляется мысль - просто адаптировать коллайдеры под квадратные тайлы. Но тогда рушиться все. Вся простота дешевизна тайлового расчета, даже AStar начинает посасывать с навигацией (и уже хочется выкинуть его, а ты все еще в тайловой-перемещении). И я молчу про производительность.
Мне уже кажется что для кого-то 3д шутана - беги стреляй, кода будет на порядок меньше, чем для тайловой пошаговой игры, где тебе нужно все переизбирать (а я же не собираюсь писать свой движок, да?).
И вот ловишь кризис - а может ну его? И сделать просто реалтайм top-down RPG - добавить стрельбу, а чтобы не просрать дух средневековьея - засунуть пост-апокалипсис. Ведь стрельба лучше смотрится чем когда спрайты трутся близи. В общем, опять кризис почаны.
Думать, унижен, прокрастинация.
>>097683
бля ну я не такой как другие они то хуйню делают а у меня все четко разложено по уму
бля ну я не такой как другие они то хуйню делают а у меня все четко разложено по уму
728 Кб, 810x1080>>097682
Сначала нужно книгу от великого прочитать. Только гений может написать книгу по геймдизайну за 5 лет до релиза своей первой игры.
Надеюсь там рассказывается как раскрутить пустую игру на кикстартере и заработать на мододелах.
Если серьезно, кидай задумку. Игру ты на вряд ли сделаешь, а мы хоть обмусолим. Я примерно в такой же области стагнирую
>рим ворлд
Сначала нужно книгу от великого прочитать. Только гений может написать книгу по геймдизайну за 5 лет до релиза своей первой игры.
Надеюсь там рассказывается как раскрутить пустую игру на кикстартере и заработать на мододелах.
>данжеон/рим ворлд
Если серьезно, кидай задумку. Игру ты на вряд ли сделаешь, а мы хоть обмусолим. Я примерно в такой же области стагнирую
>>097621
Вообще не о чем. Многопоточность это такая штука, в которую стоит инвестировать свое время, чтобы потом задница не сгорела от странных плавающих проблем.
А вы тоже в годот видосах смотрите какая у челиков видеокарта? :3
Вообще не о чем. Многопоточность это такая штука, в которую стоит инвестировать свое время, чтобы потом задница не сгорела от странных плавающих проблем.
А вы тоже в годот видосах смотрите какая у челиков видеокарта? :3
Аноны, посоветуйте готовые бесплатные библиотеки, куски кода открытых проектов и, возможно, ассеты для:
1 пошаговой jrpg боёвки
2 перемещения по локации как в elin или rpg maker (квадратная сетка), дискретные ходы, угол обзора не важен.
3 диалогов, как в визуальных новеллах
4 генерации локаций
Это, вроде, не сложно сделать, но, наверняка, до меня это уже 100 раз в годоте делали и лучше просто скопировать. Поэтому я сам не тороплюсь начинать, а готовлюсь пока.
1 пошаговой jrpg боёвки
2 перемещения по локации как в elin или rpg maker (квадратная сетка), дискретные ходы, угол обзора не важен.
3 диалогов, как в визуальных новеллах
4 генерации локаций
Это, вроде, не сложно сделать, но, наверняка, до меня это уже 100 раз в годоте делали и лучше просто скопировать. Поэтому я сам не тороплюсь начинать, а готовлюсь пока.
>>097688
Пошаговые бои на системе AP
Четыре клана, у каждого своя глазная техника и узоры. Прокачка до трёх стадий, а через события в битвах смертельные раны, смерть родственника, может пробудиться высшая форма: 20 уникальных вариантов узор отображаемых прямо на кукле персонажа. Способности жгут здоровье глаза, так что можно ослепнуть навсегда. Глаза разрешено пересаживать и собирать комбинации заклинаний разных кланов.
Оружие учебное оружие для всех но первых же боях оно навсегда превращается в уникальный тип (от генов и атрибутов) - (двуручный меч, катана, парные серпы, сюрикены и так далее ), получает свой скин и случайный модификатор, а позже открывает особые приёмы.
Стихии (Огонь, Вода, Молния, Земля, Воздух) пробуждаются прямо по ходу сражений. Можно выучить до трёх случайных заклинаний.
Тело собрано из отдельных частей: голова, торс, руки, ноги, органы. Критические удары вызывают кровотечения, переломы, пробивают броню. Шрамы и травмы остаются навсегда и отображается на скине персонажа.
Бойцов можно выращивать (до определённого момента). Они наследуют около полусотни генов: цвет волос, склонность к стихиям, атрибуты, модификаторы оружия. Взрослеют за несколько недель и сразу идут в бой. Потеря бойца — это разрыв рода.
Игровой цикл строится на турнирах один на один и миссиях. Персонажи растут по принципу «что тренируешь, то и качается», плюс большое древо перков. Погибшие попадают на кладбище с полной историей жизни. Выжившие сражаются, пока не останется последний — он уходит в Новую игру+ как финальный босс.
Пошаговые бои на системе AP
Четыре клана, у каждого своя глазная техника и узоры. Прокачка до трёх стадий, а через события в битвах смертельные раны, смерть родственника, может пробудиться высшая форма: 20 уникальных вариантов узор отображаемых прямо на кукле персонажа. Способности жгут здоровье глаза, так что можно ослепнуть навсегда. Глаза разрешено пересаживать и собирать комбинации заклинаний разных кланов.
Оружие учебное оружие для всех но первых же боях оно навсегда превращается в уникальный тип (от генов и атрибутов) - (двуручный меч, катана, парные серпы, сюрикены и так далее ), получает свой скин и случайный модификатор, а позже открывает особые приёмы.
Стихии (Огонь, Вода, Молния, Земля, Воздух) пробуждаются прямо по ходу сражений. Можно выучить до трёх случайных заклинаний.
Тело собрано из отдельных частей: голова, торс, руки, ноги, органы. Критические удары вызывают кровотечения, переломы, пробивают броню. Шрамы и травмы остаются навсегда и отображается на скине персонажа.
Бойцов можно выращивать (до определённого момента). Они наследуют около полусотни генов: цвет волос, склонность к стихиям, атрибуты, модификаторы оружия. Взрослеют за несколько недель и сразу идут в бой. Потеря бойца — это разрыв рода.
Игровой цикл строится на турнирах один на один и миссиях. Персонажи растут по принципу «что тренируешь, то и качается», плюс большое древо перков. Погибшие попадают на кладбище с полной историей жизни. Выжившие сражаются, пока не останется последний — он уходит в Новую игру+ как финальный босс.
>>097693
Начинаем смотреть, а потом теряем сознание, с частичной потерей памяти.
> А вы тоже в годот видосах смотрите какая у челиков видеокарта? :3
Начинаем смотреть, а потом теряем сознание, с частичной потерей памяти.
>>097707
Пробовал выключить и включить?
>Начинаем смотреть, а потом теряем сознание, с частичной потерей памяти.
Пробовал выключить и включить?
>>097704
Что это?
Обязательно покажи демку всего этого если санитары не отберут
Мне больше было интересно как ты совместишь даркест данжеон и римворлд и главное зачем? Сама по себе боевка в римке не самая плохая, чтобы превращать это в пошаговую. Но вот ближний бой там идиотский (судя по видосам, в начале ближнего боя не было, это было чисто ковбойский вариант). Это говорит о том, что начальный дизайн всегда определяет игру (а люди постоянно начинают с процедурной генерации, вместо основного геймплея).
Делай.
> на системе AP
Что это?
>паста
Обязательно покажи демку всего этого если санитары не отберут
Мне больше было интересно как ты совместишь даркест данжеон и римворлд и главное зачем? Сама по себе боевка в римке не самая плохая, чтобы превращать это в пошаговую. Но вот ближний бой там идиотский (судя по видосам, в начале ближнего боя не было, это было чисто ковбойский вариант). Это говорит о том, что начальный дизайн всегда определяет игру (а люди постоянно начинают с процедурной генерации, вместо основного геймплея).
Делай.
168 Кб, 689x170>>097713
AP- action point это что бы каждый удар мечем/магия стоит свое количество очков действий,
в рим ворлде боевка просто авто-бой где ты один раз команду дал и персонаж режет/стреляет, для целей римворлда достаточно, но если игра про сами бои такая система не подходит, потому что в рамках боя нужно использовать десяток видов атак/бафоф/расходников предметов
AP- action point это что бы каждый удар мечем/магия стоит свое количество очков действий,
в рим ворлде боевка просто авто-бой где ты один раз команду дал и персонаж режет/стреляет, для целей римворлда достаточно, но если игра про сами бои такая система не подходит, потому что в рамках боя нужно использовать десяток видов атак/бафоф/расходников предметов
>>097719
Если разделять на тактическую и стратегическую карту то римка это уже тактическая карта.
Например есть герои3 - ты ходишь по миру - стратегическая. Сам бой на поле это тактический.
Как ты хочешь переключить из плавной анимации в пошаговую на одном и том же типе карты?
Посмотри как популярные игроки мансят группами и разводят пачки. Там много контроля с паузами. Просто люди привыкли к киллбоксам.
ИМХО: лучше сделать полностью автоматических юнитов, чтобы они в ближнем бою сходились с врагами, а ты просто кастовал скиллы/ауры на минимальной скорости (без нудятины в виде шагов)
Если разделять на тактическую и стратегическую карту то римка это уже тактическая карта.
Например есть герои3 - ты ходишь по миру - стратегическая. Сам бой на поле это тактический.
Как ты хочешь переключить из плавной анимации в пошаговую на одном и том же типе карты?
>в рим ворлде боевка просто авто-бой где ты один раз команду дал
Посмотри как популярные игроки мансят группами и разводят пачки. Там много контроля с паузами. Просто люди привыкли к киллбоксам.
ИМХО: лучше сделать полностью автоматических юнитов, чтобы они в ближнем бою сходились с врагами, а ты просто кастовал скиллы/ауры на минимальной скорости (без нудятины в виде шагов)
>>097726
у меня в идеи нету стратегической карты
есть один хаб где делаются всякие улучшение, тренировки, магазин, выбор режимы турнира
и вторая сцена уже самой битвы тоесть это как в даркест данжеон хаб -> битва, только твой противник не абстрактный скелет, а реальный персонаж другого клана который так же учавствуется в боях, так же получает травмы, пробуждает способности, тоесть он существует даже за кадром и их десяток
а сам бой детализирован как по системе римворлда, что бы каждая поврежденные орган/отрубленная конечность влияла на атрибуты персонажа
как ты говоришь в римворлде тоже паузят/мансят группы врагов, но ведь это обрубок получается, тот же самый пошаг только с двумя действиями, атаковать -> отойти и так по кругу, лучше это же систему развернуть в глубину что бы игрок принимал решение какой скилл нажать сейчас, как накопить очков что бы билд синергировал с доступными заклинаниями, пробафаться сейчас что бы потом раздать критов, это полноценный слой тактики и мне кажется он необходим в игре которая буквально строится на этих боях, а то получится МЯСОКУБ со 2 пика
история сама пишется
у меня в идеи нету стратегической карты
есть один хаб где делаются всякие улучшение, тренировки, магазин, выбор режимы турнира
и вторая сцена уже самой битвы тоесть это как в даркест данжеон хаб -> битва, только твой противник не абстрактный скелет, а реальный персонаж другого клана который так же учавствуется в боях, так же получает травмы, пробуждает способности, тоесть он существует даже за кадром и их десяток
а сам бой детализирован как по системе римворлда, что бы каждая поврежденные орган/отрубленная конечность влияла на атрибуты персонажа
как ты говоришь в римворлде тоже паузят/мансят группы врагов, но ведь это обрубок получается, тот же самый пошаг только с двумя действиями, атаковать -> отойти и так по кругу, лучше это же систему развернуть в глубину что бы игрок принимал решение какой скилл нажать сейчас, как накопить очков что бы билд синергировал с доступными заклинаниями, пробафаться сейчас что бы потом раздать критов, это полноценный слой тактики и мне кажется он необходим в игре которая буквально строится на этих боях, а то получится МЯСОКУБ со 2 пика
история сама пишется
Мальчик, библиотек нам принеси. Мы игру года делаем.
>>097726
Так бы и сказал что хочешь здоровье и повреждения по органам. Потому что когда вспоминают римку думают о другом совсем.
В пошаговых играх именно тактическая составляющая быстро надоедает, даже в серии тотал вар хочется скипнуть бой (может у меня только так). Поэтому отказ от стратегической карты может быть ошибка (ради чего играть - у тебя нет приключения, бой ради боя)
Так бы и сказал что хочешь здоровье и повреждения по органам. Потому что когда вспоминают римку думают о другом совсем.
В пошаговых играх именно тактическая составляющая быстро надоедает, даже в серии тотал вар хочется скипнуть бой (может у меня только так). Поэтому отказ от стратегической карты может быть ошибка (ради чего играть - у тебя нет приключения, бой ради боя)
>>097732
ну как бы бой и является самим приключением, он наполнен историей сам по себе, генерация историй, уникальные билды прокачки, вон в slay the spire смотришь в отзывах там люди по 50-600 часов наигрывают, в боевке ее и заключен весь смысл путешествия
ну как бы бой и является самим приключением, он наполнен историей сам по себе, генерация историй, уникальные билды прокачки, вон в slay the spire смотришь в отзывах там люди по 50-600 часов наигрывают, в боевке ее и заключен весь смысл путешествия
>>097735
Я не играл но, по фото это около ККИ? У кки отдельный пласт стимуляций и мотиваций.
Я скажу через призму херстоуна.
Во первых выпадение карт случайно, а значит каждый бой не похож на предыдущий (что и угнетает в пошаговом тактическом бое именно тактическом, потому что всякие цивилизации и гладиусы норм заходят, даже на 10часов игры одной сессии). Ты буквально испытываешь всплеск гормонов в башке когда выпадает или не выпадает нужная карта (в нужной момент). Мне думается там стимуляции на уровне лудомании (когда тебе победная комбинация выпадает в сложном бою).
Во вторых это коллекционирование - это сильный стимул (даже гаче не снились те донаты).
В третьих билдостроение и синергии карт. Собрать синергию в колоде это круче чем бой.
Что-то там еще есть, но мне лень вспоминать. Но в тоже время ты не сделаешь коллекционных монстров, это другая иммерсивность. Юнит живой и должен умирать, не умирающий юнит сразу режет восприятие.
>Slay the Spire
Я не играл но, по фото это около ККИ? У кки отдельный пласт стимуляций и мотиваций.
Я скажу через призму херстоуна.
Во первых выпадение карт случайно, а значит каждый бой не похож на предыдущий (что и угнетает в пошаговом тактическом бое именно тактическом, потому что всякие цивилизации и гладиусы норм заходят, даже на 10часов игры одной сессии). Ты буквально испытываешь всплеск гормонов в башке когда выпадает или не выпадает нужная карта (в нужной момент). Мне думается там стимуляции на уровне лудомании (когда тебе победная комбинация выпадает в сложном бою).
Во вторых это коллекционирование - это сильный стимул (даже гаче не снились те донаты).
В третьих билдостроение и синергии карт. Собрать синергию в колоде это круче чем бой.
Что-то там еще есть, но мне лень вспоминать. Но в тоже время ты не сделаешь коллекционных монстров, это другая иммерсивность. Юнит живой и должен умирать, не умирающий юнит сразу режет восприятие.
>>097590
Если кратко: это костыль для говнокода.
>>097591
RTFM и следи за новостями движка почаще:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#variadic-functions
Но сам я не проверял такого рода говнокоды.
>>097620
Попробуй сделать шаг назад, посмотреть на свою архитектуру со стороны и попытаться объяснить конкретную проблему тому, кто не разбирается в ней (резиновой утке, LLM чатботу, гдачерам ИТТ). Тогда, возможно, к тебе придёт осознание, как будет лучше.
Думаю, главное, это осознать, что абсолютно любая видеоигра "пошаговая" из-за чёткого деления всего происходящего на экране на дискретные кадры - единственное отличие "экшена" от, скажем, простых шахмат, является то, что "экшен" имеет действие по умолчанию, называемое "idle", которое выбирается автоматически, если игрок не нажимает кнопки. Т.е. пошаговость никуда не девается, просто шаг экшена сокращается до 1/60 секунды или даже меньше.
В экшен-играх редко требуется ждать завершения множества событий, следовательно, и в геймплее пошаговой игры этого делать не стоит. Ты просто передвигаешь фишки по доске - один раз за шаг - и возвращаешься к слушанью ввода игрока. Где тут приходится ожидать несколько сигналов? Нигде.
>Почему из коробки нет WaitGroup?
Если кратко: это костыль для говнокода.
>>097591
>может быть разное число аргументов
RTFM и следи за новостями движка почаще:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#variadic-functions
Но сам я не проверял такого рода говнокоды.
>>097620
>А в пошаговой херне без WaitGroup вообще тяжко
Попробуй сделать шаг назад, посмотреть на свою архитектуру со стороны и попытаться объяснить конкретную проблему тому, кто не разбирается в ней (резиновой утке, LLM чатботу, гдачерам ИТТ). Тогда, возможно, к тебе придёт осознание, как будет лучше.
Думаю, главное, это осознать, что абсолютно любая видеоигра "пошаговая" из-за чёткого деления всего происходящего на экране на дискретные кадры - единственное отличие "экшена" от, скажем, простых шахмат, является то, что "экшен" имеет действие по умолчанию, называемое "idle", которое выбирается автоматически, если игрок не нажимает кнопки. Т.е. пошаговость никуда не девается, просто шаг экшена сокращается до 1/60 секунды или даже меньше.
В экшен-играх редко требуется ждать завершения множества событий, следовательно, и в геймплее пошаговой игры этого делать не стоит. Ты просто передвигаешь фишки по доске - один раз за шаг - и возвращаешься к слушанью ввода игрока. Где тут приходится ожидать несколько сигналов? Нигде.
>>097652
Бред какой-то, зачем тебе это? Если я не ошибаюсь, большинство пошаговых игр делает 99% мобов/NPC одноклеточными, как и игрок. Да-да, как ты себе и представил: маленькая крыска/змейка занимает на клеточном поле столько же, сколько 4-хметровый турбокачок с громадной битой, и эта же клетка приравнивается к дверному проёму. Единственное исключение - какие-то супер-мега-боссы, которые фиксируются в центре арены и никуда не ходят.
Это называется "игровая условность". В шахматах, к примеру, все фигуры занимают одну клетку, хотя они символизируют разные по размеру ИРЛ объекты. Тут главное, это подумать: нужны ли объекты с разными габаритами для геймплея или нет? Что они дадут? Реалистичность ради реалистичности оставь ААА киношникам, делающим мокап циркового медведя с единственной целью "сделать прям как в жЫзни!!!".
Ну а если тебе прям очень нужен противник, который блокирует своей тушей 2x2 клетки, то я не вижу здесь совершенно никакой проблемы. Ты просто заюзаешь банальный код Тетриса, который пишется даже без специального игрового движка за один вечер и используется с совершенно любой геометрией.
>например волк/медведь занимает уже два тайла, а тролль все четыре - ты уже думаешь в рамках body-коллайдеров, а не одного тайла.
Бред какой-то, зачем тебе это? Если я не ошибаюсь, большинство пошаговых игр делает 99% мобов/NPC одноклеточными, как и игрок. Да-да, как ты себе и представил: маленькая крыска/змейка занимает на клеточном поле столько же, сколько 4-хметровый турбокачок с громадной битой, и эта же клетка приравнивается к дверному проёму. Единственное исключение - какие-то супер-мега-боссы, которые фиксируются в центре арены и никуда не ходят.
Это называется "игровая условность". В шахматах, к примеру, все фигуры занимают одну клетку, хотя они символизируют разные по размеру ИРЛ объекты. Тут главное, это подумать: нужны ли объекты с разными габаритами для геймплея или нет? Что они дадут? Реалистичность ради реалистичности оставь ААА киношникам, делающим мокап циркового медведя с единственной целью "сделать прям как в жЫзни!!!".
Ну а если тебе прям очень нужен противник, который блокирует своей тушей 2x2 клетки, то я не вижу здесь совершенно никакой проблемы. Ты просто заюзаешь банальный код Тетриса, который пишется даже без специального игрового движка за один вечер и используется с совершенно любой геометрией.
>>097746
Вообще это база там где есть корутины. Не помню как называется в дотнете, но в го это точно WaitGroup.
Я хз, я порой гуглю чистое API и даже в документацию попасть не могу. Какое-то безумие с этими вашими нейронками.
Да, это упростило код. Ты странный, кидаешься, но все равно помогаешь. Значит еще не все потеряно с тобой.
https://hastebin.com/share/zehunagere.go
Меня пока все устраивает. Я не хочу метод дробить на 3-4 сигнала, когда есть корутины. Тем более там такая тесная и местечковая логика (буквально подождать твин итд), что вообще не хочется гадить в сигналы.
Помогли бы анонимные функции (хендлеры), но лучше одна обертка чем где-то обосраться потом в лямбде
Почему надо ждать? Да потому что надо видеть шаг и не допустить прокликивание (перс просто полетит как в реалтайме). А в дальнейшем нельзя допускать чтобы весь мир прокликивался быстро (это шахматы, а не экшн). Ну и в целом в стоуншарде иногда не чувствуется ход в бою, этого я хочу избежать. И надо еще решать проблему дабл-клика мышки у людей. Это в вебе раньше было сложно поймать эту фигню, тут это легко будет
>Если кратко: это костыль для говнокода.
Вообще это база там где есть корутины. Не помню как называется в дотнете, но в го это точно WaitGroup.
>RTFM и следи за новостями движка почаще:
Я хз, я порой гуглю чистое API и даже в документацию попасть не могу. Какое-то безумие с этими вашими нейронками.
Да, это упростило код. Ты странный, кидаешься, но все равно помогаешь. Значит еще не все потеряно с тобой.
https://hastebin.com/share/zehunagere.go
>и в геймплее пошаговой игры этого делать не стоит
Меня пока все устраивает. Я не хочу метод дробить на 3-4 сигнала, когда есть корутины. Тем более там такая тесная и местечковая логика (буквально подождать твин итд), что вообще не хочется гадить в сигналы.
Помогли бы анонимные функции (хендлеры), но лучше одна обертка чем где-то обосраться потом в лямбде
Почему надо ждать? Да потому что надо видеть шаг и не допустить прокликивание (перс просто полетит как в реалтайме). А в дальнейшем нельзя допускать чтобы весь мир прокликивался быстро (это шахматы, а не экшн). Ну и в целом в стоуншарде иногда не чувствуется ход в бою, этого я хочу избежать. И надо еще решать проблему дабл-клика мышки у людей. Это в вебе раньше было сложно поймать эту фигню, тут это легко будет
>>097732
Блин, ну не умеешь, не любишь играть в тактику - не вылезай со своими советами "это надоест", когда тут анонимус твёрдо и чётко хочет сделать свою тактику. Игровой жанр существует, у него есть свои фанаты, аудитория. Ты же не попадаешь в эту аудиторию - не проблема, играй в другие игры, и разрабатывай свои в других жанрах. Зачем мешать другим геймдевам?
Ты пришёл на детскую площадку, увидел, как дети в кукольный домик играют, и начал: "а чё это вы тут с куколками играете, это же быстро надоедает, вот возьмите набор юного тракториста, перебирайте реалистичную модель дизельного двигателя!" - это нормально вообще? Кто ты после этого, а? Тут всё практически то же, только анонимус хочет своих виртуальных куколок и чтоб они месили друг друга до соплей, крови и шрамов. Чё ты к нему пристал?
>>097704
Я вижу, ты сильно увлечён своей идеей игры, и много напридумывал уже. Советую притормозить немного, проанализировать задумки и выделить главное - тот фундамент, без которого всё остальное не работает. Реализуй этот фундамент без графики и деталей, чтоб получился играбельный прототип, а потом уже думай, интегрировать какие-то дополнительные детали или отложить на потом. А то у тебя сейчас много всего, и непонятно, как всё это будет балансироваться - я-то приблизительно понял все твои идеи, но сплести из отдельных идей целую игру всегда очень сложно.
>тактическая составляющая быстро надоедает
Блин, ну не умеешь, не любишь играть в тактику - не вылезай со своими советами "это надоест", когда тут анонимус твёрдо и чётко хочет сделать свою тактику. Игровой жанр существует, у него есть свои фанаты, аудитория. Ты же не попадаешь в эту аудиторию - не проблема, играй в другие игры, и разрабатывай свои в других жанрах. Зачем мешать другим геймдевам?
Ты пришёл на детскую площадку, увидел, как дети в кукольный домик играют, и начал: "а чё это вы тут с куколками играете, это же быстро надоедает, вот возьмите набор юного тракториста, перебирайте реалистичную модель дизельного двигателя!" - это нормально вообще? Кто ты после этого, а? Тут всё практически то же, только анонимус хочет своих виртуальных куколок и чтоб они месили друг друга до соплей, крови и шрамов. Чё ты к нему пристал?
>>097704
Я вижу, ты сильно увлечён своей идеей игры, и много напридумывал уже. Советую притормозить немного, проанализировать задумки и выделить главное - тот фундамент, без которого всё остальное не работает. Реализуй этот фундамент без графики и деталей, чтоб получился играбельный прототип, а потом уже думай, интегрировать какие-то дополнительные детали или отложить на потом. А то у тебя сейчас много всего, и непонятно, как всё это будет балансироваться - я-то приблизительно понял все твои идеи, но сплести из отдельных идей целую игру всегда очень сложно.
>>097752
Потом покажу. Простыми словами - мишка длинный и юнит залезает на спрайт. А так юнит будет бить ему по жопе. Очень сильно ощущается проблема с мини-боссами, ты либо пытаешь в тайле уместиться, а хочешь все равно жирнича и спрайты налезают (в стонике есть момент когда вообще не видно из-за суммонов босса), либо просто уже сделать честный 2х2
Так же урон по области (например огненное поле). Если игрок видит что юнит цепляет огонь - значит правда должен цеплять.
Абалдеть.
Уже научились ходить
https://rutube.ru/video/9bd401f4c2f64b03f688bb3b60e8c3ce/
Все это напишется, но когда по соседству готовые коллайдеры, как-то завидно, что можно вообще о таких деталях не думать (надо же поныть).
>Бред какой-то, зачем тебе это?
Потом покажу. Простыми словами - мишка длинный и юнит залезает на спрайт. А так юнит будет бить ему по жопе. Очень сильно ощущается проблема с мини-боссами, ты либо пытаешь в тайле уместиться, а хочешь все равно жирнича и спрайты налезают (в стонике есть момент когда вообще не видно из-за суммонов босса), либо просто уже сделать честный 2х2
Так же урон по области (например огненное поле). Если игрок видит что юнит цепляет огонь - значит правда должен цеплять.
>Да-да, как ты себе и представил: маленькая крыска/змейка занимает на клеточном поле столько же,
Абалдеть.
>Единственное исключение - какие-то супер-мега-боссы, которые фиксируются в центре арены и никуда не ходят.
Уже научились ходить
https://rutube.ru/video/9bd401f4c2f64b03f688bb3b60e8c3ce/
>Ты просто заюзаешь банальный код Тетриса, который пишется даже без специального игрового движка за один вечер и используется с совершенно любой геометрией.
Все это напишется, но когда по соседству готовые коллайдеры, как-то завидно, что можно вообще о таких деталях не думать (надо же поныть).
>>097763
да не, чел мне все по делу писал, нужно тоже со всех сторон обдумывать вкатит или нет игрокам, а так да понятно в планах просто каждую механику задуманную в единичном экземпляре собрать и сидеть месяцами множить мясо на готовый скелет
да не, чел мне все по делу писал, нужно тоже со всех сторон обдумывать вкатит или нет игрокам, а так да понятно в планах просто каждую механику задуманную в единичном экземпляре собрать и сидеть месяцами множить мясо на готовый скелет
>>097763
Стратегии и пошаговые самые мои любые жанры.
Я не говорю что нельзя сделать интересную пошаговую. Есть вариант с 3D, где анимация как в экшене тебя развлекает, есть фулл пошаговые где игра тебя держит стратегией и планированием, есть рандомайзер ККИ (но плохой рандомайзер как XCOM), есть билдостроение. А есть герои где ты играешь одним отрядом убер-стрелков или одним и тем же прокастом.
>Блин, ну не умеешь, не любишь играть в тактику
Стратегии и пошаговые самые мои любые жанры.
Я не говорю что нельзя сделать интересную пошаговую. Есть вариант с 3D, где анимация как в экшене тебя развлекает, есть фулл пошаговые где игра тебя держит стратегией и планированием, есть рандомайзер ККИ (но плохой рандомайзер как XCOM), есть билдостроение. А есть герои где ты играешь одним отрядом убер-стрелков или одним и тем же прокастом.
>>097767
А есть боевые братки. Просто дикий дефицит в тактике, но из-за одушевления юнитов ты ощущаешь ценность каждого в отряде.
Вот этот стример привносит просто дикую иммерсивность для относительно пустой игры.
https://www.youtube.com/watch?v=s46G5SBVBO8&list=PLbWv5TDR2JwC0DsdGsMfHieSuqY-X6DTE
А есть боевые братки. Просто дикий дефицит в тактике, но из-за одушевления юнитов ты ощущаешь ценность каждого в отряде.
Вот этот стример привносит просто дикую иммерсивность для относительно пустой игры.
https://www.youtube.com/watch?v=s46G5SBVBO8&list=PLbWv5TDR2JwC0DsdGsMfHieSuqY-X6DTE
>>097756
Н-не то, что бы я хотел п-помочь такому т-тупому быдлокодеру, просто... Просто я мимо проходил и... Случайно вспомнил нужную информацию. Не пойми неправильно, это не потому что... Аргх! (ударил в лоб, покраснев, словно помидор, развернулся и убежал)
Имхо, лучше делать в точности наоборот: разрешать полностью скипать все ненужные анимации ходов, "ускоряя" геймплей по требованию игрока вплоть до "реалтаймового", если игрок будет достаточно шустро прожимать все клавиши действий. Это база, без этой функции играть в пошаговые игры тяжко и скучно.
Вот как я вижу идеальный пошаговый синглплеер:
1. Игрок видит статичное состояние мира.
2. Игрок выбирает своё следующее действие.
3. Игра СРАЗУ ЖЕ переходит на следующий шаг.
4. Игра запускает анимации, типа:
5. ЕСЛИ игрок нажмёт кнопку действия:
5.1. Игра скипает все анимации:
5.2. Переходим на шаг 3.
6. Если игрок ничего не нажал, переходим к 1.
Такая схема позволяет игрокам:
- играть (думать) так медленно, как они хотят;
- быстро скипать любые скучные моменты игры.
Ну, да, нужна задержка ~100 мс против дабл-клика.
>>097765
Ты смешиваешь проблемы спрайтов с проблемами геймплея... Раньше такие игры ASCII символы юзали вообще, и нормально выглядело, потом вместо этих символов нацепили 32x32 спрайты и стало КРУТО, а некоторые даже 3D модели умудряются сделать. Т.е. геймплей задаёт формат графики, а не наоборот. Ну, разумеется, бывают проблемы из-за наложения нескольких спрайтов, но игроки к этому привычны, определить положение обычно поможно с помощью дополнительного экрана/GUI с точной информацией.
Ты же не симулятор ходьбы по спрайтам делаешь, от спрайтов нужно только чтобы игрок мог определить опасного врага/ценный лут/безопасное место, без специальной книжки со списком "(B) - это bear, а (b) - barrel, смотри не перепутай, когда делаешь /piss".
Ну а если хочешь красоту наводить, то, наверное, ты перепутал жанр, и нужно делать экшон, суть токова: ходишь красивой тянкой по подземельям, лупишь монстриков няшных в бубен, если проиграл - сценка прикольная на половину экрана, а самое приятное - респавн без потери лута... одежду покупать можно... подземные корованы грабить... Джве минуты хочу.
>Ты странный, кидаешься, но все равно помогаешь.
Н-не то, что бы я хотел п-помочь такому т-тупому быдлокодеру, просто... Просто я мимо проходил и... Случайно вспомнил нужную информацию. Не пойми неправильно, это не потому что... Аргх! (ударил в лоб, покраснев, словно помидор, развернулся и убежал)
>не допустить прокликивание
Имхо, лучше делать в точности наоборот: разрешать полностью скипать все ненужные анимации ходов, "ускоряя" геймплей по требованию игрока вплоть до "реалтаймового", если игрок будет достаточно шустро прожимать все клавиши действий. Это база, без этой функции играть в пошаговые игры тяжко и скучно.
Вот как я вижу идеальный пошаговый синглплеер:
1. Игрок видит статичное состояние мира.
2. Игрок выбирает своё следующее действие.
3. Игра СРАЗУ ЖЕ переходит на следующий шаг.
4. Игра запускает анимации, типа:
>tween.tween_property(self, "position", actual_pos, time)
5. ЕСЛИ игрок нажмёт кнопку действия:
5.1. Игра скипает все анимации:
>if tween: tween.kill() # прерывание
>position = actual_pos # скачок
5.2. Переходим на шаг 3.
6. Если игрок ничего не нажал, переходим к 1.
Такая схема позволяет игрокам:
- играть (думать) так медленно, как они хотят;
- быстро скипать любые скучные моменты игры.
Ну, да, нужна задержка ~100 мс против дабл-клика.
>>097765
Ты смешиваешь проблемы спрайтов с проблемами геймплея... Раньше такие игры ASCII символы юзали вообще, и нормально выглядело, потом вместо этих символов нацепили 32x32 спрайты и стало КРУТО, а некоторые даже 3D модели умудряются сделать. Т.е. геймплей задаёт формат графики, а не наоборот. Ну, разумеется, бывают проблемы из-за наложения нескольких спрайтов, но игроки к этому привычны, определить положение обычно поможно с помощью дополнительного экрана/GUI с точной информацией.
Ты же не симулятор ходьбы по спрайтам делаешь, от спрайтов нужно только чтобы игрок мог определить опасного врага/ценный лут/безопасное место, без специальной книжки со списком "(B) - это bear, а (b) - barrel, смотри не перепутай, когда делаешь /piss".
Ну а если хочешь красоту наводить, то, наверное, ты перепутал жанр, и нужно делать экшон, суть токова: ходишь красивой тянкой по подземельям, лупишь монстриков няшных в бубен, если проиграл - сценка прикольная на половину экрана, а самое приятное - респавн без потери лута... одежду покупать можно... подземные корованы грабить... Джве минуты хочу.
>>097756
Н-не то, что бы я хотел п-помочь такому т-тупому быдлокодеру, просто... Просто я мимо проходил и... Случайно вспомнил нужную информацию. Не пойми неправильно, это не потому что... Аргх! (ударил в лоб, покраснев, словно помидор, развернулся и убежал)
Имхо, лучше делать в точности наоборот: разрешать полностью скипать все ненужные анимации ходов, "ускоряя" геймплей по требованию игрока вплоть до "реалтаймового", если игрок будет достаточно шустро прожимать все клавиши действий. Это база, без этой функции играть в пошаговые игры тяжко и скучно.
Вот как я вижу идеальный пошаговый синглплеер:
1. Игрок видит статичное состояние мира.
2. Игрок выбирает своё следующее действие.
3. Игра СРАЗУ ЖЕ переходит на следующий шаг.
4. Игра запускает анимации, типа:
5. ЕСЛИ игрок нажмёт кнопку действия:
5.1. Игра скипает все анимации:
5.2. Переходим на шаг 3.
6. Если игрок ничего не нажал, переходим к 1.
Такая схема позволяет игрокам:
- играть (думать) так медленно, как они хотят;
- быстро скипать любые скучные моменты игры.
Ну, да, нужна задержка ~100 мс против дабл-клика.
>>097765
Ты смешиваешь проблемы спрайтов с проблемами геймплея... Раньше такие игры ASCII символы юзали вообще, и нормально выглядело, потом вместо этих символов нацепили 32x32 спрайты и стало КРУТО, а некоторые даже 3D модели умудряются сделать. Т.е. геймплей задаёт формат графики, а не наоборот. Ну, разумеется, бывают проблемы из-за наложения нескольких спрайтов, но игроки к этому привычны, определить положение обычно поможно с помощью дополнительного экрана/GUI с точной информацией.
Ты же не симулятор ходьбы по спрайтам делаешь, от спрайтов нужно только чтобы игрок мог определить опасного врага/ценный лут/безопасное место, без специальной книжки со списком "(B) - это bear, а (b) - barrel, смотри не перепутай, когда делаешь /piss".
Ну а если хочешь красоту наводить, то, наверное, ты перепутал жанр, и нужно делать экшон, суть токова: ходишь красивой тянкой по подземельям, лупишь монстриков няшных в бубен, если проиграл - сценка прикольная на половину экрана, а самое приятное - респавн без потери лута... одежду покупать можно... подземные корованы грабить... Джве минуты хочу.
>Ты странный, кидаешься, но все равно помогаешь.
Н-не то, что бы я хотел п-помочь такому т-тупому быдлокодеру, просто... Просто я мимо проходил и... Случайно вспомнил нужную информацию. Не пойми неправильно, это не потому что... Аргх! (ударил в лоб, покраснев, словно помидор, развернулся и убежал)
>не допустить прокликивание
Имхо, лучше делать в точности наоборот: разрешать полностью скипать все ненужные анимации ходов, "ускоряя" геймплей по требованию игрока вплоть до "реалтаймового", если игрок будет достаточно шустро прожимать все клавиши действий. Это база, без этой функции играть в пошаговые игры тяжко и скучно.
Вот как я вижу идеальный пошаговый синглплеер:
1. Игрок видит статичное состояние мира.
2. Игрок выбирает своё следующее действие.
3. Игра СРАЗУ ЖЕ переходит на следующий шаг.
4. Игра запускает анимации, типа:
>tween.tween_property(self, "position", actual_pos, time)
5. ЕСЛИ игрок нажмёт кнопку действия:
5.1. Игра скипает все анимации:
>if tween: tween.kill() # прерывание
>position = actual_pos # скачок
5.2. Переходим на шаг 3.
6. Если игрок ничего не нажал, переходим к 1.
Такая схема позволяет игрокам:
- играть (думать) так медленно, как они хотят;
- быстро скипать любые скучные моменты игры.
Ну, да, нужна задержка ~100 мс против дабл-клика.
>>097765
Ты смешиваешь проблемы спрайтов с проблемами геймплея... Раньше такие игры ASCII символы юзали вообще, и нормально выглядело, потом вместо этих символов нацепили 32x32 спрайты и стало КРУТО, а некоторые даже 3D модели умудряются сделать. Т.е. геймплей задаёт формат графики, а не наоборот. Ну, разумеется, бывают проблемы из-за наложения нескольких спрайтов, но игроки к этому привычны, определить положение обычно поможно с помощью дополнительного экрана/GUI с точной информацией.
Ты же не симулятор ходьбы по спрайтам делаешь, от спрайтов нужно только чтобы игрок мог определить опасного врага/ценный лут/безопасное место, без специальной книжки со списком "(B) - это bear, а (b) - barrel, смотри не перепутай, когда делаешь /piss".
Ну а если хочешь красоту наводить, то, наверное, ты перепутал жанр, и нужно делать экшон, суть токова: ходишь красивой тянкой по подземельям, лупишь монстриков няшных в бубен, если проиграл - сценка прикольная на половину экрана, а самое приятное - респавн без потери лута... одежду покупать можно... подземные корованы грабить... Джве минуты хочу.
>>097769
Забавно это слышать от человека который не знает про WaitGroup, а корутины это быдлокод.
Когда начнешь делать игры - увидишь что такой переход выглядит мгновенным и непонятным для игрока (нет вообще перехода, чистая телепортация). В оригинале даже добавили небольшой прыжок, чтобы ощущался фидбэк от клика/шага.
У меня прыжок по параболе как затычка, в реале там немного по другому сделано, чтобы вне боя двигаться почти реалтайм.
Норм получится, не переживай. Еще через год присоединишься к проекту, я тебя знаю.
>быдлокодеру
Забавно это слышать от человека который не знает про WaitGroup, а корутины это быдлокод.
>Игра СРАЗУ ЖЕ переходит на следующий шаг.
Когда начнешь делать игры - увидишь что такой переход выглядит мгновенным и непонятным для игрока (нет вообще перехода, чистая телепортация). В оригинале даже добавили небольшой прыжок, чтобы ощущался фидбэк от клика/шага.
У меня прыжок по параболе как затычка, в реале там немного по другому сделано, чтобы вне боя двигаться почти реалтайм.
Норм получится, не переживай. Еще через год присоединишься к проекту, я тебя знаю.
>>097780
Они тут в отрицании всего, что касается нейронок. Тяжелая травма от общения с Алисой. Небось до сих пор код руками пишут.
Они тут в отрицании всего, что касается нейронок. Тяжелая травма от общения с Алисой. Небось до сих пор код руками пишут.
>>097776
Забавно видеть человека, не знающего о цундерах...
Ну, удачи с игрой, в которой игрок делает так:
1. Ткнул влево (вправо/вверх/вниз).
2. Подождал 1-2-5-10 секунд анимации...
3. Повторил 1-2 шаги 100-500 раз, зевая от скуки.
4. Оооо, геймплей!!!! ...это слайм на 3.5 шага...
5. Повторяем с шага 1 до тошноты.
6. Умер от скуки (и механики голода).
Ещё добавь супер-долгие катсцены, будет 10/10.
К т-тебе?! Да ни за что на свете!.. д-дурашка...
>>097780
В чём смысл поста если ты мог спросить чатжпт?
>Забавно это слышать от человека который не знает
Забавно видеть человека, не знающего о цундерах...
>переход выглядит мгновенным и непонятным
Ну, удачи с игрой, в которой игрок делает так:
1. Ткнул влево (вправо/вверх/вниз).
2. Подождал 1-2-5-10 секунд анимации...
3. Повторил 1-2 шаги 100-500 раз, зевая от скуки.
4. Оооо, геймплей!!!! ...это слайм на 3.5 шага...
5. Повторяем с шага 1 до тошноты.
6. Умер от скуки (и механики голода).
Ещё добавь супер-долгие катсцены, будет 10/10.
>Еще через год присоединишься к проекту
К т-тебе?! Да ни за что на свете!.. д-дурашка...
>>097780
В чём смысл поста если ты мог спросить чатжпт?
>>097782
Да, ты еще предложишь другое название. Название реально поменяем, а стиль оставим. Это я точно помню. Из-за тебя потом уйдет часть кор команды на втором проекте.
>К т-тебе?! Да ни за что на свете!.. д-дурашка...
Да, ты еще предложишь другое название. Название реально поменяем, а стиль оставим. Это я точно помню. Из-за тебя потом уйдет часть кор команды на втором проекте.
>>097784
Как всегда нейродебил пытается усидеть на всех стульях. Используя еще примитивные приемы лести, чтобы сосать токены у далеких от технической области людей.
Как всегда нейродебил пытается усидеть на всех стульях. Используя еще примитивные приемы лести, чтобы сосать токены у далеких от технической области людей.
>>097688
Кстати, есть годная общепризнанная библия геймдева? Чтоб ёмко без размусоливаний
Кстати, есть годная общепризнанная библия геймдева? Чтоб ёмко без размусоливаний
60 Кб, 700x700>>097803
У тебя есть знания, которые могу приносить миллионы долларов даже не работая. То есть, качество таких знаний позволяют полностью инвестировать и не работать - только руководить (или расписать ТЗ). Но вместо этого ты год-два-три пишешь книгу, постоянно перечитываешь, фиксишь, еще издатель тебе фиксы присылает. И в итоге за 4 года продаж ты получаешь 50-100$, вместо миллионов за свои знания.
Что-то не очень, да?
Запомни «Кто умеет — делает, кто не умеет — тот учит»
У тебя есть знания, которые могу приносить миллионы долларов даже не работая. То есть, качество таких знаний позволяют полностью инвестировать и не работать - только руководить (или расписать ТЗ). Но вместо этого ты год-два-три пишешь книгу, постоянно перечитываешь, фиксишь, еще издатель тебе фиксы присылает. И в итоге за 4 года продаж ты получаешь 50-100$, вместо миллионов за свои знания.
Что-то не очень, да?
Запомни «Кто умеет — делает, кто не умеет — тот учит»
>>097707
Да ладно, обычная ноутбучная встройка, ничего выдающегося
Да ладно, обычная ноутбучная встройка, ничего выдающегося
а что если сделать свой движок и в нем сделать игрушку где ты типо грибок и прыгаешь по супер марио ?
302 Кб, 1920x1439>>097787
Хммм, не могу понять - это ad hominem или на ступеньку выше?
В любом случае, растёшь! Хотя бы не просто поток оскорблений.
>>097784
Базированная нейротянучка, молодец! Всё знаешь! Так держать!
>>097786
Ты тут кого-то с кем-то перепутал или я не знаю твоего мема...
>>097813
Можно быть тренером и при этом не быть мастером спорта.
>нейродебил
>Используя еще примитивные приемы лести
Хммм, не могу понять - это ad hominem или на ступеньку выше?
В любом случае, растёшь! Хотя бы не просто поток оскорблений.
>>097784
Базированная нейротянучка, молодец! Всё знаешь! Так держать!
>>097786
Ты тут кого-то с кем-то перепутал или я не знаю твоего мема...
>>097813
Можно быть тренером и при этом не быть мастером спорта.
>>097867
Ты говно!
Тренер как раз нужен как субличность, а не учитель. Он тренирует/развивает тебя и дополняет (учит только в начале). Например матч - ты выпал в тильт из-за неудачи, но в реале все еще можно перевернуть. Сам ты из под тильты это не сделаешь никогда (поверь), а тренер сбросит эту херню.
Возведи меня в авторитет и представь я буду каждый день приходить и наставлять тебя делать игру. И уже не будет такого "ладно, еще одну серию аниме посмотрю". Удобно же
>В любом случае, растёшь! Хотя бы не просто поток оскорблений.
Ты говно!
>Можно быть тренером и при этом не быть мастером спорта.
Тренер как раз нужен как субличность, а не учитель. Он тренирует/развивает тебя и дополняет (учит только в начале). Например матч - ты выпал в тильт из-за неудачи, но в реале все еще можно перевернуть. Сам ты из под тильты это не сделаешь никогда (поверь), а тренер сбросит эту херню.
Возведи меня в авторитет и представь я буду каждый день приходить и наставлять тебя делать игру. И уже не будет такого "ладно, еще одну серию аниме посмотрю". Удобно же
>>097876
Речь не о том, что делает тренер/учитель, а о том, что у человека может не быть возможности или даже желания самостоятельно достичь чего-то, но есть возможность или желание помочь кому-то другому достичь этого. Вот ты говоришь про "миллионы денег", а разве все люди хотят достичь "миллионов денег" любой ценой? Есть масса людей, которым хочется просто расслабляться и ничего не делать. Они могут расслабляться после смены на заводе или в офисе, и не стремиться к повышению зарплаты, потому что им не нужно. Если у такого человека ВНЕЗАПНО есть какой-то опыт и глубокие мысли по геймдеву, он не побежит сломя голову договариваться с инвесторами, издателями и площадками, собирать и управлять сотрудниками, вести налоговый учёт, арендовать офис и машины, и строить свою ММОРПГ, которая перевернёт весь мир - но он мог бы передать свои мысли кому-то, кому не лень заниматься всем этим и получить профит.
По крайней мере, в теории, такие люди точно должны существовать, и они наверняка написали какие-то книги. Но я подобными книгами никогда не интересовался, так что не знаю. Я пробовал начать читать пару книжек на тему геймдизайна - не затянуло, я вообще только форумы читаю последние несколько лет. Но говорить "все книги написаны шарлатанами, которые ничего не знают и не понимают, потому что если б знали и понимали, то не писали бы" - как-то глупо, попахивает какой-то теорией заговора, по которой все люди действуют одинаково и обязательно в корыстных целях.
Речь не о том, что делает тренер/учитель, а о том, что у человека может не быть возможности или даже желания самостоятельно достичь чего-то, но есть возможность или желание помочь кому-то другому достичь этого. Вот ты говоришь про "миллионы денег", а разве все люди хотят достичь "миллионов денег" любой ценой? Есть масса людей, которым хочется просто расслабляться и ничего не делать. Они могут расслабляться после смены на заводе или в офисе, и не стремиться к повышению зарплаты, потому что им не нужно. Если у такого человека ВНЕЗАПНО есть какой-то опыт и глубокие мысли по геймдеву, он не побежит сломя голову договариваться с инвесторами, издателями и площадками, собирать и управлять сотрудниками, вести налоговый учёт, арендовать офис и машины, и строить свою ММОРПГ, которая перевернёт весь мир - но он мог бы передать свои мысли кому-то, кому не лень заниматься всем этим и получить профит.
По крайней мере, в теории, такие люди точно должны существовать, и они наверняка написали какие-то книги. Но я подобными книгами никогда не интересовался, так что не знаю. Я пробовал начать читать пару книжек на тему геймдизайна - не затянуло, я вообще только форумы читаю последние несколько лет. Но говорить "все книги написаны шарлатанами, которые ничего не знают и не понимают, потому что если б знали и понимали, то не писали бы" - как-то глупо, попахивает какой-то теорией заговора, по которой все люди действуют одинаково и обязательно в корыстных целях.
>>097885
Ты возводишь до бинарного мышления. Почему сразу шарлатаны? Там скорее всего есть какая-то информация, но ценность такой информации сомнительная.
Ты уже пришел из мира игр и уже скорее всего будешь просто повторять какие-то удобные вещи.
Там был эксперимент, вкратце сажали людей которые никогда не играли и они терялись в базовых вещах которые известны нам игрокам. Так же я с девушкой играл, она тоже терялась в каких-то примитивных вещах, о которых я даже не задумывался и делал по интуиции.
Просто играй - повторяй удобное - все, весь геймдизайн (если только тебе не нужно разводить людей на алмазики).
А помнишь у тебя была мечта? Сколько мыслей ты тратил на обдумывание геймплея, иногда даже не мог заснуть? А помнишь ту радость и то чувство когда что-то у тебя получалось? Сражу же хотелось даже поделиться, хотя для всех остальных это полная фигня.
Хочешь получить доступ к этому потоку снова? Хочешь этот порыв вместо "прийти с работы и играть, смотреть тупо в экран?". Неужели "это" лучше чем тот вайб?
>"все книги написаны шарлатанами,
Ты возводишь до бинарного мышления. Почему сразу шарлатаны? Там скорее всего есть какая-то информация, но ценность такой информации сомнительная.
Ты уже пришел из мира игр и уже скорее всего будешь просто повторять какие-то удобные вещи.
Там был эксперимент, вкратце сажали людей которые никогда не играли и они терялись в базовых вещах которые известны нам игрокам. Так же я с девушкой играл, она тоже терялась в каких-то примитивных вещах, о которых я даже не задумывался и делал по интуиции.
Просто играй - повторяй удобное - все, весь геймдизайн (если только тебе не нужно разводить людей на алмазики).
> Есть масса людей, которым хочется просто расслабляться и ничего не делать. Они могут расслабляться после смены на заводе или в офисе, и не стремиться к повышению зарплаты, потому что им не нужно.
А помнишь у тебя была мечта? Сколько мыслей ты тратил на обдумывание геймплея, иногда даже не мог заснуть? А помнишь ту радость и то чувство когда что-то у тебя получалось? Сражу же хотелось даже поделиться, хотя для всех остальных это полная фигня.
Хочешь получить доступ к этому потоку снова? Хочешь этот порыв вместо "прийти с работы и играть, смотреть тупо в экран?". Неужели "это" лучше чем тот вайб?
>>097895
Хмм... Есть куча подводных камней, которые трудно заметить, когда ты как игрок делаешь свою собственную игру.
Например, банальное управление: ты привык к определённым клавишам, и даже не задумываешься о том, что кому-то приходится ребиндить клавиши на другие, и в итоге не делаешь ребинд клавиш по всей игре, и из-за этого кто-то страдает.
Баги: ты привык, что у тебя в игре что-то сломано, и забыл пофиксить, потому что интуитивно прожимаешь самую безопасную комбинацию, а игроки этой комбинации не знают и будут тыкаться в софт-локи и баттхёртить из-за незаметного для тебя бага.
Упрощение (QoL) игры: ты можешь накрутить кучу разнообразных механик и потом сломать всю игру одним новым дополнением, которое делает все механики ненужными, не догадываясь, что многие игроки выбирают по умолчанию путь наименьшего сопротивления, а не самый фановый путь; например, твоя игра имеет много механик перемещения и интересные для исследования карты, а ты позже внедряешь в игру необходимость бегать за 20 км и телепорты для быстрого скипа этого бега за 20 км - в итоге все твои игроки только и делают, что телепортируются, а механики движения и все эти красоты на карте остаются никому не нужными, и игроки жалуются, что игра "пустая".
Также и с балансом противников: тебе может казаться, что реально умные враги - это 10/10 механика, ведь тебе известно, как твои NPC организуют свои нападения, перемещаются где-то за стенами и обходят игрока со спины, и тебе известно, где этих NPC поймать и как их скрытно убить, а игроку всё это неизвестно - с его точки зрения, игра тупо заспавнила читерских мобов и несправедливо убила его, всё, он рейджквайнтул, удалил игру, написал злобный отзыв и больше не вернётся.
Мультиплеер - это вообще ад для дизайна из-за того, что все люди разные и среди широкой аудитории обязательно найдутся абьюзеры, гриферы, читеры и прочий сброд, который найдёт любую уязвимость в твоей игре, чтобы сознательно испортить настроение другим игрокам, и не всегда ты можешь "легально" наказать их, не навредив честным игрокам/не нарушив правила.
Большинство игроков не задумываются о таких нюансах, потому что разработчики оставляют всё это за кулисами... Поэтому "просто играть и повторять удобное" недостаточно для достаточно хорошей, надёжной, устойчивой, весёлой для всей своей ЦА игры.
Что-то я не понял, к чему ты это написал. Я так-то безработный...
>ценность такой информации сомнительная
>Просто играй - повторяй удобное - все, весь геймдизайн
Хмм... Есть куча подводных камней, которые трудно заметить, когда ты как игрок делаешь свою собственную игру.
Например, банальное управление: ты привык к определённым клавишам, и даже не задумываешься о том, что кому-то приходится ребиндить клавиши на другие, и в итоге не делаешь ребинд клавиш по всей игре, и из-за этого кто-то страдает.
Баги: ты привык, что у тебя в игре что-то сломано, и забыл пофиксить, потому что интуитивно прожимаешь самую безопасную комбинацию, а игроки этой комбинации не знают и будут тыкаться в софт-локи и баттхёртить из-за незаметного для тебя бага.
Упрощение (QoL) игры: ты можешь накрутить кучу разнообразных механик и потом сломать всю игру одним новым дополнением, которое делает все механики ненужными, не догадываясь, что многие игроки выбирают по умолчанию путь наименьшего сопротивления, а не самый фановый путь; например, твоя игра имеет много механик перемещения и интересные для исследования карты, а ты позже внедряешь в игру необходимость бегать за 20 км и телепорты для быстрого скипа этого бега за 20 км - в итоге все твои игроки только и делают, что телепортируются, а механики движения и все эти красоты на карте остаются никому не нужными, и игроки жалуются, что игра "пустая".
Также и с балансом противников: тебе может казаться, что реально умные враги - это 10/10 механика, ведь тебе известно, как твои NPC организуют свои нападения, перемещаются где-то за стенами и обходят игрока со спины, и тебе известно, где этих NPC поймать и как их скрытно убить, а игроку всё это неизвестно - с его точки зрения, игра тупо заспавнила читерских мобов и несправедливо убила его, всё, он рейджквайнтул, удалил игру, написал злобный отзыв и больше не вернётся.
Мультиплеер - это вообще ад для дизайна из-за того, что все люди разные и среди широкой аудитории обязательно найдутся абьюзеры, гриферы, читеры и прочий сброд, который найдёт любую уязвимость в твоей игре, чтобы сознательно испортить настроение другим игрокам, и не всегда ты можешь "легально" наказать их, не навредив честным игрокам/не нарушив правила.
Большинство игроков не задумываются о таких нюансах, потому что разработчики оставляют всё это за кулисами... Поэтому "просто играть и повторять удобное" недостаточно для достаточно хорошей, надёжной, устойчивой, весёлой для всей своей ЦА игры.
>А помнишь у тебя была мечта?
Что-то я не понял, к чему ты это написал. Я так-то безработный...
>>097895
Хмм... Есть куча подводных камней, которые трудно заметить, когда ты как игрок делаешь свою собственную игру.
Например, банальное управление: ты привык к определённым клавишам, и даже не задумываешься о том, что кому-то приходится ребиндить клавиши на другие, и в итоге не делаешь ребинд клавиш по всей игре, и из-за этого кто-то страдает.
Баги: ты привык, что у тебя в игре что-то сломано, и забыл пофиксить, потому что интуитивно прожимаешь самую безопасную комбинацию, а игроки этой комбинации не знают и будут тыкаться в софт-локи и баттхёртить из-за незаметного для тебя бага.
Упрощение (QoL) игры: ты можешь накрутить кучу разнообразных механик и потом сломать всю игру одним новым дополнением, которое делает все механики ненужными, не догадываясь, что многие игроки выбирают по умолчанию путь наименьшего сопротивления, а не самый фановый путь; например, твоя игра имеет много механик перемещения и интересные для исследования карты, а ты позже внедряешь в игру необходимость бегать за 20 км и телепорты для быстрого скипа этого бега за 20 км - в итоге все твои игроки только и делают, что телепортируются, а механики движения и все эти красоты на карте остаются никому не нужными, и игроки жалуются, что игра "пустая".
Также и с балансом противников: тебе может казаться, что реально умные враги - это 10/10 механика, ведь тебе известно, как твои NPC организуют свои нападения, перемещаются где-то за стенами и обходят игрока со спины, и тебе известно, где этих NPC поймать и как их скрытно убить, а игроку всё это неизвестно - с его точки зрения, игра тупо заспавнила читерских мобов и несправедливо убила его, всё, он рейджквайнтул, удалил игру, написал злобный отзыв и больше не вернётся.
Мультиплеер - это вообще ад для дизайна из-за того, что все люди разные и среди широкой аудитории обязательно найдутся абьюзеры, гриферы, читеры и прочий сброд, который найдёт любую уязвимость в твоей игре, чтобы сознательно испортить настроение другим игрокам, и не всегда ты можешь "легально" наказать их, не навредив честным игрокам/не нарушив правила.
Большинство игроков не задумываются о таких нюансах, потому что разработчики оставляют всё это за кулисами... Поэтому "просто играть и повторять удобное" недостаточно для достаточно хорошей, надёжной, устойчивой, весёлой для всей своей ЦА игры.
Что-то я не понял, к чему ты это написал. Я так-то безработный...
>ценность такой информации сомнительная
>Просто играй - повторяй удобное - все, весь геймдизайн
Хмм... Есть куча подводных камней, которые трудно заметить, когда ты как игрок делаешь свою собственную игру.
Например, банальное управление: ты привык к определённым клавишам, и даже не задумываешься о том, что кому-то приходится ребиндить клавиши на другие, и в итоге не делаешь ребинд клавиш по всей игре, и из-за этого кто-то страдает.
Баги: ты привык, что у тебя в игре что-то сломано, и забыл пофиксить, потому что интуитивно прожимаешь самую безопасную комбинацию, а игроки этой комбинации не знают и будут тыкаться в софт-локи и баттхёртить из-за незаметного для тебя бага.
Упрощение (QoL) игры: ты можешь накрутить кучу разнообразных механик и потом сломать всю игру одним новым дополнением, которое делает все механики ненужными, не догадываясь, что многие игроки выбирают по умолчанию путь наименьшего сопротивления, а не самый фановый путь; например, твоя игра имеет много механик перемещения и интересные для исследования карты, а ты позже внедряешь в игру необходимость бегать за 20 км и телепорты для быстрого скипа этого бега за 20 км - в итоге все твои игроки только и делают, что телепортируются, а механики движения и все эти красоты на карте остаются никому не нужными, и игроки жалуются, что игра "пустая".
Также и с балансом противников: тебе может казаться, что реально умные враги - это 10/10 механика, ведь тебе известно, как твои NPC организуют свои нападения, перемещаются где-то за стенами и обходят игрока со спины, и тебе известно, где этих NPC поймать и как их скрытно убить, а игроку всё это неизвестно - с его точки зрения, игра тупо заспавнила читерских мобов и несправедливо убила его, всё, он рейджквайнтул, удалил игру, написал злобный отзыв и больше не вернётся.
Мультиплеер - это вообще ад для дизайна из-за того, что все люди разные и среди широкой аудитории обязательно найдутся абьюзеры, гриферы, читеры и прочий сброд, который найдёт любую уязвимость в твоей игре, чтобы сознательно испортить настроение другим игрокам, и не всегда ты можешь "легально" наказать их, не навредив честным игрокам/не нарушив правила.
Большинство игроков не задумываются о таких нюансах, потому что разработчики оставляют всё это за кулисами... Поэтому "просто играть и повторять удобное" недостаточно для достаточно хорошей, надёжной, устойчивой, весёлой для всей своей ЦА игры.
>А помнишь у тебя была мечта?
Что-то я не понял, к чему ты это написал. Я так-то безработный...
>>097885
Двачую.
>>097813
Есть еще проще аргумент.
Мы сидим в треде опенсорс движка. По логике того постера, его бы не раздавали бесплатно, ведь на знаниях, заложенных в его написание, можно было заработать миллионы.
Есть разные причины, почему люди делятся знаниями. Очевидный пример, когда уже делал игры и вышел на пенсию. Или когда нет навыка "инвестировать" или навыка "управлять другими через написание ТЗ" или устал от этого.
Двачую.
>>097813
Есть еще проще аргумент.
Мы сидим в треде опенсорс движка. По логике того постера, его бы не раздавали бесплатно, ведь на знаниях, заложенных в его написание, можно было заработать миллионы.
Есть разные причины, почему люди делятся знаниями. Очевидный пример, когда уже делал игры и вышел на пенсию. Или когда нет навыка "инвестировать" или навыка "управлять другими через написание ТЗ" или устал от этого.
>>097901
Ты будешь и так с лупой смотреть другие игры которые копируешь (я вчера смотрел на скорости 0.25 анимацию). Только практика. Только хардкор.
>>097903
Вот из-за таких умозаключений ты и бедный. Около технические книги пишут чтобы заработать. Поэтому есть 100500 книг по синтаксису С++, но 1,5 книги что делать с этим С++ дальше (это условно, но реально 90-99% книг это покрытие рынка спроса вкатунцов, а не альтруизм. Реальные сложные темы где нужна информация - ты будешь выгрызать кровью и потом, а писать их никто не будет, потому мало кто купит).
Ты будешь и так с лупой смотреть другие игры которые копируешь (я вчера смотрел на скорости 0.25 анимацию). Только практика. Только хардкор.
>>097903
Вот из-за таких умозаключений ты и бедный. Около технические книги пишут чтобы заработать. Поэтому есть 100500 книг по синтаксису С++, но 1,5 книги что делать с этим С++ дальше (это условно, но реально 90-99% книг это покрытие рынка спроса вкатунцов, а не альтруизм. Реальные сложные темы где нужна информация - ты будешь выгрызать кровью и потом, а писать их никто не будет, потому мало кто купит).
>>097813
Очень ограниченное понимание. Немало успешных людей переходят на новый уровень - обучение своему опыту. Это новая ступень удовлетворения своих потребностей. По себе знаю. И задача тут найти среди инфоцыганского мусора вот именно таких
>Запомни «Кто умеет — делает, кто не умеет — тот учит»
Очень ограниченное понимание. Немало успешных людей переходят на новый уровень - обучение своему опыту. Это новая ступень удовлетворения своих потребностей. По себе знаю. И задача тут найти среди инфоцыганского мусора вот именно таких
>>097916
Да, только опять почти все книги только по вкату. Офигенно когда у тебя опыт 20 лет и ты решил поделиться знаниями о синтаксисе (особенно когда с годами некоторые тонкости забываешь и не используешь).
>>097917
Не закрывайся от нас, мы с тобой.
Кто еще поддержит тебя когда ты снова сорвешься?
Да, только опять почти все книги только по вкату. Офигенно когда у тебя опыт 20 лет и ты решил поделиться знаниями о синтаксисе (особенно когда с годами некоторые тонкости забываешь и не используешь).
>>097917
>Не. Сегодня у тебя вангование не задалось.
Не закрывайся от нас, мы с тобой.
Кто еще поддержит тебя когда ты снова сорвешься?
7 Кб, 230x96Чет я затрахался инициализировать все ручками.
Какие подводные такого подхода (мы вешаем прям чисто скрипт как ноду)?
Именно случаи когда объект представлен в виде единичного сервиса (а не пачки экземпляров, где такой подход не подойдет).
Мнение? Это выглядит по ньюфаже, но мне правда интересно кто использует такой подход или кто обжегся. С локатором вроде как удобно, но засоряет сцену.
Какие подводные такого подхода (мы вешаем прям чисто скрипт как ноду)?
Именно случаи когда объект представлен в виде единичного сервиса (а не пачки экземпляров, где такой подход не подойдет).
Мнение? Это выглядит по ньюфаже, но мне правда интересно кто использует такой подход или кто обжегся. С локатором вроде как удобно, но засоряет сцену.
>>097928
Сорвётся делать игры? Делать игры же?
>>097903
База. А ведь сколько безызвестных движков было написано в надежде на продажи...
>>097913
Почему ты всё про книги да про книги (которые давно бесплатно можно качать с официальных сайтов в PDF, а не только покупать макулатуру в местном книжном)? Существует масса ютуберов, которые точно так же снимают туториалы по базовым основам какого-то инструмента, а на более сложных темах пукают и обмякают. На что они рассчитывают? Платные курсы делать? Для кого, если они и так всё давно уже бесплатно рассказали? На патреоне сочувствующих собирать? Тоже такая себе затея, если ты не топ среди топов.
Просто существует такой тип людей, которым нравится поучать кого-нибудь тому, что они узнали, даже если поверхностно. Вот есть задроты, которые читают энциклопедию от корки до корки и могли бы ответить на любой вопрос о жизни, вселенной и всём таком, но первыми никогда не заговаривают о своих знаниях. А есть те, кто открыл энциклопедию на случайной странице, прочитал один абзац, охнул от удивления, и поскорее побежал рассказывать всем, кого знает, в стиле "а вы знали, что у многоножек дыхательный аппарат на каждом сегменте тела, а не как у других животных, а ещё он не закрывается, поэтому они вынуждены жить во влажной среде" - если спросить такого о каких-то подробностях, он без понятия, он не биолог, он просто поделился теми крупицами информации, которые его самого увлекли. А когда делиться вот совсем не с кем и при этом в жопе сверлит желание - идёшь на ютуб со своими рассказами, или блог в интернете заводишь, книгу пишешь...
По сути, у таких людей нет ни времени, ни терпения изучать предмет в глубину. Но делиться им не терпится.
>когда ты снова сорвешься
Сорвётся делать игры? Делать игры же?
>>097903
>сидим в треде опенсорс движка
База. А ведь сколько безызвестных движков было написано в надежде на продажи...
>>097913
>пишут чтобы заработать. Поэтому есть 100500 книг по синтаксису С++...
Почему ты всё про книги да про книги (которые давно бесплатно можно качать с официальных сайтов в PDF, а не только покупать макулатуру в местном книжном)? Существует масса ютуберов, которые точно так же снимают туториалы по базовым основам какого-то инструмента, а на более сложных темах пукают и обмякают. На что они рассчитывают? Платные курсы делать? Для кого, если они и так всё давно уже бесплатно рассказали? На патреоне сочувствующих собирать? Тоже такая себе затея, если ты не топ среди топов.
Просто существует такой тип людей, которым нравится поучать кого-нибудь тому, что они узнали, даже если поверхностно. Вот есть задроты, которые читают энциклопедию от корки до корки и могли бы ответить на любой вопрос о жизни, вселенной и всём таком, но первыми никогда не заговаривают о своих знаниях. А есть те, кто открыл энциклопедию на случайной странице, прочитал один абзац, охнул от удивления, и поскорее побежал рассказывать всем, кого знает, в стиле "а вы знали, что у многоножек дыхательный аппарат на каждом сегменте тела, а не как у других животных, а ещё он не закрывается, поэтому они вынуждены жить во влажной среде" - если спросить такого о каких-то подробностях, он без понятия, он не биолог, он просто поделился теми крупицами информации, которые его самого увлекли. А когда делиться вот совсем не с кем и при этом в жопе сверлит желание - идёшь на ютуб со своими рассказами, или блог в интернете заводишь, книгу пишешь...
По сути, у таких людей нет ни времени, ни терпения изучать предмет в глубину. Но делиться им не терпится.
>>097938
Какие подводные ты ожидаешь? Ну создал ноды и создал. Ты хочешь узнать, может ли движок заглючить и сломаться? Может ли потеряться какой-то блок данных? Или ты про то, можешь ли ты случайно выстрелить себе в ногу говнокодом и потом мучиться рефакторингом? Само по себе добавление нод ни к чему не приведёт, это самая базовая операция Godot. А последствия для поддержки тобой твоего кода зависят от того, что ты там с этим кодом в нодах делаешь и зачем... Я вот с первого взгляда не понимаю, что и зачем ты разбил на 4 отдельных ноды - у тебя уже есть код или это пустышки? Если пустышки, лучше сначала в одном скрипте набросай, потом порежешь на части по настроению...
Алсо, чисто субъективное, но я бы назвал так:
Без лишних "менеджеров", и тем более без приставок. Ты же дерево составляешь, в дереве сразу видно "приставку" в виде родителя, который по умолчанию является "менеджером" для всех своих детей, поскольку управляет их жизнью (за редким исключением "прыгающей" по дереву ноды, которая никому кроме себя не принадлежит, хотя и меняет родителей).
Другой пример:
Тут очевидно же, что нода NPC - "менеджер NPC", а ноды-потомки - это сами NPC.
Какие подводные ты ожидаешь? Ну создал ноды и создал. Ты хочешь узнать, может ли движок заглючить и сломаться? Может ли потеряться какой-то блок данных? Или ты про то, можешь ли ты случайно выстрелить себе в ногу говнокодом и потом мучиться рефакторингом? Само по себе добавление нод ни к чему не приведёт, это самая базовая операция Godot. А последствия для поддержки тобой твоего кода зависят от того, что ты там с этим кодом в нодах делаешь и зачем... Я вот с первого взгляда не понимаю, что и зачем ты разбил на 4 отдельных ноды - у тебя уже есть код или это пустышки? Если пустышки, лучше сначала в одном скрипте набросай, потом порежешь на части по настроению...
Алсо, чисто субъективное, но я бы назвал так:
>Turn
>- State
>- Input
>- Step
Без лишних "менеджеров", и тем более без приставок. Ты же дерево составляешь, в дереве сразу видно "приставку" в виде родителя, который по умолчанию является "менеджером" для всех своих детей, поскольку управляет их жизнью (за редким исключением "прыгающей" по дереву ноды, которая никому кроме себя не принадлежит, хотя и меняет родителей).
Другой пример:
>NPC
>- Alice
>- Betty
>- Carla
Тут очевидно же, что нода NPC - "менеджер NPC", а ноды-потомки - это сами NPC.
>>097943
this
>>097943
Ну класс должен иметь одну ответственность - база.
Менеджер - главный скрипт отвечающий за переходы, в нем регистрируются все "шагающие", он переключает и исполняет. Главный управленец.
State - все состояния (аля стейтмашина без машины), просто чтобы в менеджер не срать и отделить состояния от простых переменных.
Input - тут все перехваты импутов для игры, по идеи надо делать отдельно, но чет пока на практике импуты сильно завязаны к контексту игры, я прям в Turn и засунул (скажем для UI в другое место положу).
Step - есть общий код (движения, атака итд.), пока тут лежит, еще не сообразил как лучше сделать.
Хотелось бы, но нет namespace. У меня этих "State" уже 3 штуки. Приходится всегда прификсы писать.
Только что проверил - без названия "class_name" нельзя прикрепить чисто скрипт. Но можно создать просто ноду2д и к нему уже прикрепить скрипт.
Ощущение говнокода, надо думать.
>Или ты про то, можешь ли ты случайно выстрелить себе в ногу говнокодом и потом мучиться рефакторингом?
this
>>097943
>Я вот с первого взгляда не понимаю, что и зачем ты разбил на 4 отдельных ноды
Ну класс должен иметь одну ответственность - база.
Менеджер - главный скрипт отвечающий за переходы, в нем регистрируются все "шагающие", он переключает и исполняет. Главный управленец.
State - все состояния (аля стейтмашина без машины), просто чтобы в менеджер не срать и отделить состояния от простых переменных.
Input - тут все перехваты импутов для игры, по идеи надо делать отдельно, но чет пока на практике импуты сильно завязаны к контексту игры, я прям в Turn и засунул (скажем для UI в другое место положу).
Step - есть общий код (движения, атака итд.), пока тут лежит, еще не сообразил как лучше сделать.
>Алсо, чисто субъективное, но я бы назвал так:
Хотелось бы, но нет namespace. У меня этих "State" уже 3 штуки. Приходится всегда прификсы писать.
Только что проверил - без названия "class_name" нельзя прикрепить чисто скрипт. Но можно создать просто ноду2д и к нему уже прикрепить скрипт.
Ощущение говнокода, надо думать.
Чтобы не было недопонимания и срача. Я знаю что вы пишите через компоненты и сигналы. Но есть подход организации кода через менеджеры.
>>097969
Можешь реализовать подмену стандартного SceneTree на свой:
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Если эти ноды создаются и добавляются в рантайме через add_child(), тогда, возможно, тебе вообще не нужны ноды - достаточно будет RefCounted. Если тебе нужны какие-то @export параметры, но не нужны ноды, тогда достаточно будет Resource. Если будешь делать через RefCounted, то не обязательно даже выносить в отдельный .gd файл, т.к. существуют "inner classes", которые описываются типа такого:
И так далее, всё в одном файле. Единственный минус внутренних классов - они не могут быть потомками Node/Resource, только Object/RefCounted. Но к ним можно обращаться извне их файла через точку:
Если не ошибаюсь, это должно работать без проблем (давно не проверял).
>>097978
Вот только сам Godot уже "менеджерит" состояния всех нод - _process, _input и т.д. Нет необходимости навешивать что-то поверх этого, если ты изучишь, поймёшь и примешь то, как именно работает Godot. Именно поэтому мы можем кидать ноды на сцену, писать код в _process, _input и т.п. и оно "just works" - всю тяжёлую работу по менеджменту Godot уже делает под капотом, остаётся только писать свою игру.
>Менеджер - главный скрипт отвечающий за переход
Можешь реализовать подмену стандартного SceneTree на свой:
https://docs.godotengine.org/en/stable/classes/class_mainloop.html
Если эти ноды создаются и добавляются в рантайме через add_child(), тогда, возможно, тебе вообще не нужны ноды - достаточно будет RefCounted. Если тебе нужны какие-то @export параметры, но не нужны ноды, тогда достаточно будет Resource. Если будешь делать через RefCounted, то не обязательно даже выносить в отдельный .gd файл, т.к. существуют "inner classes", которые описываются типа такого:
>class_name TurnManager extends Node
>class TurnState: # подразумевается extends RefCounted, писать не обязательно
>_ var...
>_ func...
>class TurnStateIdle extends TurnState:...
И так далее, всё в одном файле. Единственный минус внутренних классов - они не могут быть потомками Node/Resource, только Object/RefCounted. Но к ним можно обращаться извне их файла через точку:
>var state := TurnManager.TurnStateIdle.new()
Если не ошибаюсь, это должно работать без проблем (давно не проверял).
>>097978
Вот только сам Godot уже "менеджерит" состояния всех нод - _process, _input и т.д. Нет необходимости навешивать что-то поверх этого, если ты изучишь, поймёшь и примешь то, как именно работает Godot. Именно поэтому мы можем кидать ноды на сцену, писать код в _process, _input и т.п. и оно "just works" - всю тяжёлую работу по менеджменту Godot уже делает под капотом, остаётся только писать свою игру.
>>097988
Тут менеджер игровой логики, не движка. Ты что-то смешал все. Я потом просто код кину, посмотришь что это, мне лень писать.
>Вот только сам Godot уже "менеджерит" состояния всех нод - _process, _input и т.д
Тут менеджер игровой логики, не движка. Ты что-то смешал все. Я потом просто код кину, посмотришь что это, мне лень писать.
делаю стелс хоррор от первого лица в качестве своей первой игры на Godot, какие подводные?
>>098000
А тут кто-то уже делал подводный хоррор в батискафе.
А тут кто-то уже делал подводный хоррор в батискафе.
Последнюю неделю после перерыва вновь начал чекать ютуб на тему вайбкодинга. Ебучий клод уже за полдня на годоте любую игру среднего уровня копирует.
Как в такой обстановке можно что-то делоть? Есть ответы у вас? Принимаются аргументированные возражения
Как в такой обстановке можно что-то делоть? Есть ответы у вас? Принимаются аргументированные возражения
>>098029
почему так?
почему так?
>>098049
скинь ссылки на готовые результаты, что там тебя так впечатлило. я пока видел только условные клоны аркадных игр, может чуть сложнее.
прикол ведь в том, что создание тетриса через вайбкод - это "make tetris" промпт, потому что само слово tetris уже содержит огромное кол-во информации. это не слово само по себе, а ссылка на массив слов "линии сгорают, очки, тетрамино, ...". но ведь если у меня некая механика достаточно конкретная и не имеет явного точного референса, то придется писать не "make mygame", потому mygame не ссылка на что-то, потому что моей игры еще нет, придется писать целиком весь массив инфы, и уже результат будет ну так сяк, ни одного проекта, размера больше чем недельный джем, при это фулл вайбкоженного, не видел пока, чтобы оно прям впечатлило.
скинь ссылки на готовые результаты, что там тебя так впечатлило. я пока видел только условные клоны аркадных игр, может чуть сложнее.
прикол ведь в том, что создание тетриса через вайбкод - это "make tetris" промпт, потому что само слово tetris уже содержит огромное кол-во информации. это не слово само по себе, а ссылка на массив слов "линии сгорают, очки, тетрамино, ...". но ведь если у меня некая механика достаточно конкретная и не имеет явного точного референса, то придется писать не "make mygame", потому mygame не ссылка на что-то, потому что моей игры еще нет, придется писать целиком весь массив инфы, и уже результат будет ну так сяк, ни одного проекта, размера больше чем недельный джем, при это фулл вайбкоженного, не видел пока, чтобы оно прям впечатлило.
>>098068
https://youtu.be/rKW0jqAAA8A
https://youtu.be/XYCyGbZIR2M
https://youtu.be/5xTj9XOHgQI
Эти особенно удивили. Платформер субмарина вообще пушка
https://youtu.be/rKW0jqAAA8A
https://youtu.be/XYCyGbZIR2M
https://youtu.be/5xTj9XOHgQI
Эти особенно удивили. Платформер субмарина вообще пушка
>>098068
Ну, справедливости ради, эти модели вышли буквально недавно и до какого либо вразумительных примеров ждать полгода-год.
Ну, справедливости ради, эти модели вышли буквально недавно и до какого либо вразумительных примеров ждать полгода-год.
>>098059
Это не работает с играми, это вообще не особо работает большинству пахую как раз.
Это не работает с играми, это вообще не особо работает большинству пахую как раз.
AnimationPlayer
1) Нельзя выбрать все кадры (хоткеем)? Можно только мышкой выделить? Нейронки советуют безумие - сделать Ctrl + A но это хоткей создание ноды
2) Нельзя масштабировать мышкой (пропорционально растягивая и сужая по времени)? Только через меню редактирования - фиксированными цифрами?
1) Нельзя выбрать все кадры (хоткеем)? Можно только мышкой выделить? Нейронки советуют безумие - сделать Ctrl + A но это хоткей создание ноды
2) Нельзя масштабировать мышкой (пропорционально растягивая и сужая по времени)? Только через меню редактирования - фиксированными цифрами?
2) Я так понял с 2021 года ждем
https://github.com/godotengine/godot-proposals/issues/3532
Ну ладно, чё. У нас у всех же есть врожденное ощущение скорости анимации
https://github.com/godotengine/godot-proposals/issues/3532
Ну ладно, чё. У нас у всех же есть врожденное ощущение скорости анимации
Один из крупнейших геймджемов.
>>097938
Это очень хороший вопрос.
Исследовал эту тему. Тут главная ошибка наследование от Node2D когда это не нужно. Для Node2D делается много телодвижений (движком меняется трансформация, дергается canvas и рендерСервер). Поэтому по возможности лучше унаследовать от Node.
НО! Node тоже не совсем бесплатная фигня, но главная проблема что очень легко вылететь в прогрессию. У тебя 20-30 нод-скриптов у юнита и ты спавнишь 100 юнитов, они в сумме породят 2000-3000 нод. От чего уже будет не так сладко. Это все еще не критично, но показывает как легко попасть в прогрессию, а движок будет делать пустые ненужные телодвижения работы с деревом.
Так что это фигня, я заведомо решил делать игру для калькуляторов, поэтому зачем самому себе гадить.
Это очень хороший вопрос.
Исследовал эту тему. Тут главная ошибка наследование от Node2D когда это не нужно. Для Node2D делается много телодвижений (движком меняется трансформация, дергается canvas и рендерСервер). Поэтому по возможности лучше унаследовать от Node.
НО! Node тоже не совсем бесплатная фигня, но главная проблема что очень легко вылететь в прогрессию. У тебя 20-30 нод-скриптов у юнита и ты спавнишь 100 юнитов, они в сумме породят 2000-3000 нод. От чего уже будет не так сладко. Это все еще не критично, но показывает как легко попасть в прогрессию, а движок будет делать пустые ненужные телодвижения работы с деревом.
Так что это фигня, я заведомо решил делать игру для калькуляторов, поэтому зачем самому себе гадить.
хз
>>098122
Они ж там игры не делают и косплеят бабок на лавках, какая им разница. А тут повод порадоваться за тулзы, которые лично ты используешь.
Они ж там игры не делают и косплеят бабок на лавках, какая им разница. А тут повод порадоваться за тулзы, которые лично ты используешь.
надо просто любое говно сделать и всегда сразу в стим, вы только посмотрите на это гавно
>>098168
Туда ли ты притащил? Тут местные гении по 10 лет пилят в стол, никому ничего не показывая, трясясь за идею. А потом пук-кек и выгорел.
>make smaller games faster
Туда ли ты притащил? Тут местные гении по 10 лет пилят в стол, никому ничего не показывая, трясясь за идею. А потом пук-кек и выгорел.
>>098169
Слышш! Ты чо! Ты уважение имей! Ты чо ээ?
Слышш! Ты чо! Ты уважение имей! Ты чо ээ?
>>098161
Да все, я не выдержал и уже обмазал там стенки палаты.
Да все, я не выдержал и уже обмазал там стенки палаты.
>>098168
Это как раз случай, когда надо выключить юношеский максимализм, включить лобные доли отвечающие за критическое мышление и начать постигал азы геймдева.
Пора.
>говно
>гавно
Это как раз случай, когда надо выключить юношеский максимализм, включить лобные доли отвечающие за критическое мышление и начать постигал азы геймдева.
Пора.
Не совсем понимаю, в заголовке про физику, в реале что-то с шейдерами.
>>098169
Я Энцо Феррари от геймдева, своим именем говно подписывать отказываюсь.
Я Энцо Феррари от геймдева, своим именем говно подписывать отказываюсь.
>>098196
Нужно чтобы богатый рантье купил игру и декомпилировал для чатика. Чисто в исследовательских целях.
Как вам идея?
>Нефига не понял
Нужно чтобы богатый рантье купил игру и декомпилировал для чатика. Чисто в исследовательских целях.
Как вам идея?
>>098194
Позиции зелёных кружков считаются в так называемом Compute Shader, т.е. на видеокарте https://docs.godotengine.org/en/latest/tutorials/shaders/compute_shaders.html
Их физика скорее всего интегрирование Верле, большего тут вроде не надо
https://www.youtube.com/watch?v=lS_qeBy3aQI
>в реале что-то с шейдерами.
Позиции зелёных кружков считаются в так называемом Compute Shader, т.е. на видеокарте https://docs.godotengine.org/en/latest/tutorials/shaders/compute_shaders.html
Их физика скорее всего интегрирование Верле, большего тут вроде не надо
https://www.youtube.com/watch?v=lS_qeBy3aQI
205 Кб, 600x500>>098243
Спасибо, впитаю попозже.
Спасибо, впитаю попозже.
>>098243
дополню:
Ну или физика, как в пиксельных играх типа Noita, с вектором гравитации направленным вправо, там вообще ещё проще, тодже есть видео всякие как сделать
>большего тут вроде не надо
дополню:
Ну или физика, как в пиксельных играх типа Noita, с вектором гравитации направленным вправо, там вообще ещё проще, тодже есть видео всякие как сделать
>>098168
Ты это и за десять лет не сделаешь. И я тоже не сделаю. Там какие-то хардкорные математики с GPGPU знаниями, добытыми потом и кровью, а не визуальная новелла или симулятор ходьбы на стандартных нодах.
Им мало игр-однодневок на 2.1 часа геймплея с бесплатными ассетами и геймплеем из 90-х? У них там совершенно не то, что может сделать 99.99% вкатунов в геймдев, прочитав "делайте маленькие игры быстрее"...
>>098104
Он пока не подходит для сложных анимаций. Хочешь сложные анимации для 3D - экспортируй из Blender. Для 2D существует множество программ, платных и бесплатных, но лично я ничего порекомендовать не могу пока.
Совет по анимации: сначала сделай все ключевые позиции - начало, конец, резкие повороты - потом проиграй и подвигай ключи, чтобы было правильное ощущение времени - и только после того, как будешь этим доволен, заполняй промежутки между ключевыми позициями интерполяцией и мелкими деталями. Тогда тебе никогда не придётся сжимать/разжимать длинную портянку ключей, кроме динамической адаптации к скорости движения, которая делается внешним параметром плеера/дерева анимаций, а не движением ключей на дорожке.
Создавать анимацию "ключ за ключом" выглядит логично только на первый взгляд новичка - потом осознаёшь, что таким способом ты никогда не сможешь попасть в нужное тебе ощущение, и переходишь на "сверху вниз" (хотя в случае дорожки правильнее сказать "снаружи вовнутрь" или "с краёв к середине").
>вы только посмотрите на это
Ты это и за десять лет не сделаешь. И я тоже не сделаю. Там какие-то хардкорные математики с GPGPU знаниями, добытыми потом и кровью, а не визуальная новелла или симулятор ходьбы на стандартных нодах.
>make smaller games faster
Им мало игр-однодневок на 2.1 часа геймплея с бесплатными ассетами и геймплеем из 90-х? У них там совершенно не то, что может сделать 99.99% вкатунов в геймдев, прочитав "делайте маленькие игры быстрее"...
>>098104
>AnimationPlayer
Он пока не подходит для сложных анимаций. Хочешь сложные анимации для 3D - экспортируй из Blender. Для 2D существует множество программ, платных и бесплатных, но лично я ничего порекомендовать не могу пока.
Совет по анимации: сначала сделай все ключевые позиции - начало, конец, резкие повороты - потом проиграй и подвигай ключи, чтобы было правильное ощущение времени - и только после того, как будешь этим доволен, заполняй промежутки между ключевыми позициями интерполяцией и мелкими деталями. Тогда тебе никогда не придётся сжимать/разжимать длинную портянку ключей, кроме динамической адаптации к скорости движения, которая делается внешним параметром плеера/дерева анимаций, а не движением ключей на дорожке.
Создавать анимацию "ключ за ключом" выглядит логично только на первый взгляд новичка - потом осознаёшь, что таким способом ты никогда не сможешь попасть в нужное тебе ощущение, и переходишь на "сверху вниз" (хотя в случае дорожки правильнее сказать "снаружи вовнутрь" или "с краёв к середине").
>>098256
Я сегодня почти сразу "угадал" скорость (и нужна была только скорость), но в теории есть speed_scale, можно подвигать ползунок, а потом относительно масштабировать все ключи.
Я сегодня почти сразу "угадал" скорость (и нужна была только скорость), но в теории есть speed_scale, можно подвигать ползунок, а потом относительно масштабировать все ключи.
>>098387
Делоть. Только вот если будет успех нейрокабанычи скопируют, а я буду сосать лапу без ресурсов на агромаркетинг
Делоть. Только вот если будет успех нейрокабанычи скопируют, а я буду сосать лапу без ресурсов на агромаркетинг
Рисовать 2D в редакторе, пока бесплатно, скачать
https://store.godotengine.org/asset/blackwater-gator-studios/gator-sprite-studio/
https://store.godotengine.org/asset/blackwater-gator-studios/gator-sprite-studio/
>>098396
Сначала подумал это pixelorama
Сначала подумал это pixelorama
4 Кб, 167x106Как же удобно. А ведь в статикодрисне пришлось бы все методы обмазать асинками.
>>098070
Это жесть. Похоже, геймдев мёртв. Всем придётся играть в Майнкрафт и другие старые игры.
Это жесть. Похоже, геймдев мёртв. Всем придётся играть в Майнкрафт и другие старые игры.
>>098420
геймдев на подьеме, игры будут все лучше и лучше более сложный и глубокие механики внедряться, щяс нельзя будет сделать залупу порашную потому что ее способен сделать каждый. мы входим в век величайших игр когда каждый способен создать что либо
геймдев на подьеме, игры будут все лучше и лучше более сложный и глубокие механики внедряться, щяс нельзя будет сделать залупу порашную потому что ее способен сделать каждый. мы входим в век величайших игр когда каждый способен создать что либо
>>098420
Кодинг де-факто теперь мертв. В вебдеве например он еще мертвей. Я код писал всю жизнь, и крайне странно за всем этим наблюдать, но что есть, то есть. Не небывали, говоря что coding is solved. Только самые тугие динозавры вроде пары местных этого не просекли и все еще потешно набирают код своими крошечными лапками. Взрывная волна метеорита и до них докатится.
Кодинг де-факто теперь мертв. В вебдеве например он еще мертвей. Я код писал всю жизнь, и крайне странно за всем этим наблюдать, но что есть, то есть. Не небывали, говоря что coding is solved. Только самые тугие динозавры вроде пары местных этого не просекли и все еще потешно набирают код своими крошечными лапками. Взрывная волна метеорита и до них докатится.
>>098434
Значит остаётся делать то, что получается у меня лучше всего: придумывать истории, сеттинги, целые вселенные, с космогоническими системами, непротиворечиво укладывающимися в общую канву. А игоры по моим историям мне сделает робот.
Значит остаётся делать то, что получается у меня лучше всего: придумывать истории, сеттинги, целые вселенные, с космогоническими системами, непротиворечиво укладывающимися в общую канву. А игоры по моим историям мне сделает робот.
>>098435
Но с этим нейронки еще лучше чем с кодом, и давно уже. Даже печатные нейрокниги давно есть.
Но с этим нейронки еще лучше чем с кодом, и давно уже. Даже печатные нейрокниги давно есть.
>>098440
Так-же, он тебе может показать как реализовать геймлуп для пошаговых перделок https://journal.stuffwithstuff.com/2014/07/15/a-turn-based-game-loop/
>пук среньк
>Боб Нистром
Так-же, он тебе может показать как реализовать геймлуп для пошаговых перделок https://journal.stuffwithstuff.com/2014/07/15/a-turn-based-game-loop/
>>098390
Если сделаешь достойную игру, а не очередной безыдейный ассетфлип (чем и являются все клоны уже успешных игр), то никакие кабанычи тебе не страшны, а даже наоборот - если они с тебя скопируют, то игроки пронюхают о существовании твоей игры через их маркетинг. То есть кабан тратит деньги на клон, тратит деньги на маркетинг, а игрок обжигается об его агрессивную монетизацию и ищет альтернативы, в результате чего находя тебя с твоим оригиналом. Просто сам не будь кабаном и люди к тебе потянутся. Конечно, есть нюанс: если кабан заявит на тебя за нарушение авторских прав, автоматическая система торговой площадки может встать на его сторону, и без судебного разбирательства твою игру не вернут. Поэтому нужно качать права первым, а не дожидаться, когда кабан решит устроить чистку конкурентов.
>>098396
Очередной ненужный велосипед с квадратными колёсами от того, кому просто заняться нечем. Лучше бы сделали какой-то более эффективный мост между Godot и другими программами, которые лучше подходят для создания контента. Пока единственная киллер-фича твоей программы в том, что она находится внутри другой программы - у тебя нет киллер-фичи, а значит, твою программу нет смысла скачивать даже бесплатно... Хотя, возможно, такие плагины могут помочь тем, у кого нет доступа к установке нормальных программ на каких-то экзотических платформах. Например, я долгое время перебирал пиксель-арт программы на Android и не нашёл ни одной, которая бы работала совсем без проблем. Если кто-то геймдевит на Godot на Android и хочет пиксель-арт редактор, ему, возможно, будет выгоднее установить плагин на Godot, чем рыться в гугл-помойке в поисках стоящей проги. Но на Windows/Linux и так достаточно программ для рисования, "победить" которые уже нереально.
>>098415
Чего ты там дожидаешься-то? Это для пошаговой игры? С await'ами можно больно выстрелить себе в ногу, если ты забудешь, кто кого ждёт, и прервёшь событие или запустишь его дважды за один раз. Я лично даже не представляю, можно ли как-то легко дебажить await? По моему опыту, Godot позволяет легко посмотреть: состояние дерева, состояние нод, состояние переменных, стек вызовов функций... Но как посмотреть, кто кого в данный момент "ждёт", я не знаю. Это отображается в стеке вызовов?.. Короче, я стараюсь не использовать await без крайней на то необходимости, когда по-другому никак. И при чём тут статические языки? В статических языках тоже бывает понятие "события"/"сигнала"...
>>098420 >>098434
Вы что, кабанчики или гребцы вёслами на галере? Не понимаю вашей паники. Вы так говорите, будто вы всю жизнь вязали одежду на продажу, а потом кабан со швейным станком не просто пришёл, а пришёл, сломал ваши спицы, сжёг клубок ниток и пропихнул закон, уголовно преследующий любого, кто попытается заниматься вязанием одежды вручную. Если вам нравится писать код вручную - никто не обязывает вас юзать нейронки, пишите сколько захотите и чего захотите. Если вам нравится делать игры вручную, с ручным артом и ручным кодом - делайте смело, никто не отберёт у вас инструменты и не прикажет генерировать нейронкой. Вы разводите панику на пустом месте, как будто завтра все компьютеры загорятся и испарятся, а всем людям вживят чипы с принудительным нейрослопом. Даже в случае какого-то глобального катаклизма, останется возможность делать кустарные компьютеры на примитивных транзисторах, программировать их вручную и делать простейшие игры на этом - так что даже в случае апокалипсиса ваши хобби будут довольно защищены от исчезновения. Разве нет?
>>098480
Креативность имеющихся сегодня LLM опирается только на генератор случайных чисел, который помогает выбрать токены, находящиеся дальше усреднённого статистически значения, но даже с ним модель стремится к чему-то статистически среднему. Более того, проблема с этой креативностью в том, что чем дальше LLM уходит от средних значений своего датасета, тем хуже становится её логика, знания деталей и интеллект в целом. Я неоднократно видел, как LLM впадает в "колею" усреднённых шаблонов, и также неоднократно видел, как LLM резко тупеет, если попытаться своими промптами "выбить из колеи", потому что LLM просто не знает, как ей действовать в описанной ситуации. Это, по всей видимости, фундаментальная проблема архитектуры и/или способа тренировки. Креативность людей в этом плане не сильно лучше, но люди хотя бы не деградируют до пускающих слюну дебилов, когда им подбрасывают незнакомую идею и предлагают что-то сочинить с ней: если писатель имеет высокий интеллект, он не потеряет его, попытавшись написать о том, о чём он раньше не писал. Другими словами, креативность LLM хороша только до тех пор, пока ты не познакомился с тем, какие шаблоны поведения заложены в эту конкретную модель конкретным датасетом; как только ты начинаешь узнавать с первого взгляда шаблоны, модель перестаёт казаться креативной, и выбить её из этого состояния без доучивания на неизвестном тебе датасете (или RLHF) просто нереально.
Но это всё не важно. Даже когда ИИ научатся эффективной креативности без потери интеллекта, возвращаемся к тому же аргументу: никто не отбирает у вас ваше воображение, вы можете сами креативить что захотите, вам это никто не запретит, никто не посадит принудительно на кучу веществ, убивающих мышление, не вырежет кусок мозга и т.д. Я думаю, стоит рассматривать ИИ скорее как партнёра по креативности, чем "замену": если раньше люди могли собираться только сами с собой для посиделок с рассказами, теперь любой сможет устроить такие посиделки с ИИ, обмениваясь с ним своими креативностями и получая от этого удовольствие. Разве это не прекрасно? Радоваться надо.
Если сделаешь достойную игру, а не очередной безыдейный ассетфлип (чем и являются все клоны уже успешных игр), то никакие кабанычи тебе не страшны, а даже наоборот - если они с тебя скопируют, то игроки пронюхают о существовании твоей игры через их маркетинг. То есть кабан тратит деньги на клон, тратит деньги на маркетинг, а игрок обжигается об его агрессивную монетизацию и ищет альтернативы, в результате чего находя тебя с твоим оригиналом. Просто сам не будь кабаном и люди к тебе потянутся. Конечно, есть нюанс: если кабан заявит на тебя за нарушение авторских прав, автоматическая система торговой площадки может встать на его сторону, и без судебного разбирательства твою игру не вернут. Поэтому нужно качать права первым, а не дожидаться, когда кабан решит устроить чистку конкурентов.
>>098396
Очередной ненужный велосипед с квадратными колёсами от того, кому просто заняться нечем. Лучше бы сделали какой-то более эффективный мост между Godot и другими программами, которые лучше подходят для создания контента. Пока единственная киллер-фича твоей программы в том, что она находится внутри другой программы - у тебя нет киллер-фичи, а значит, твою программу нет смысла скачивать даже бесплатно... Хотя, возможно, такие плагины могут помочь тем, у кого нет доступа к установке нормальных программ на каких-то экзотических платформах. Например, я долгое время перебирал пиксель-арт программы на Android и не нашёл ни одной, которая бы работала совсем без проблем. Если кто-то геймдевит на Godot на Android и хочет пиксель-арт редактор, ему, возможно, будет выгоднее установить плагин на Godot, чем рыться в гугл-помойке в поисках стоящей проги. Но на Windows/Linux и так достаточно программ для рисования, "победить" которые уже нереально.
>>098415
Чего ты там дожидаешься-то? Это для пошаговой игры? С await'ами можно больно выстрелить себе в ногу, если ты забудешь, кто кого ждёт, и прервёшь событие или запустишь его дважды за один раз. Я лично даже не представляю, можно ли как-то легко дебажить await? По моему опыту, Godot позволяет легко посмотреть: состояние дерева, состояние нод, состояние переменных, стек вызовов функций... Но как посмотреть, кто кого в данный момент "ждёт", я не знаю. Это отображается в стеке вызовов?.. Короче, я стараюсь не использовать await без крайней на то необходимости, когда по-другому никак. И при чём тут статические языки? В статических языках тоже бывает понятие "события"/"сигнала"...
>>098420 >>098434
Вы что, кабанчики или гребцы вёслами на галере? Не понимаю вашей паники. Вы так говорите, будто вы всю жизнь вязали одежду на продажу, а потом кабан со швейным станком не просто пришёл, а пришёл, сломал ваши спицы, сжёг клубок ниток и пропихнул закон, уголовно преследующий любого, кто попытается заниматься вязанием одежды вручную. Если вам нравится писать код вручную - никто не обязывает вас юзать нейронки, пишите сколько захотите и чего захотите. Если вам нравится делать игры вручную, с ручным артом и ручным кодом - делайте смело, никто не отберёт у вас инструменты и не прикажет генерировать нейронкой. Вы разводите панику на пустом месте, как будто завтра все компьютеры загорятся и испарятся, а всем людям вживят чипы с принудительным нейрослопом. Даже в случае какого-то глобального катаклизма, останется возможность делать кустарные компьютеры на примитивных транзисторах, программировать их вручную и делать простейшие игры на этом - так что даже в случае апокалипсиса ваши хобби будут довольно защищены от исчезновения. Разве нет?
>>098480
Креативность имеющихся сегодня LLM опирается только на генератор случайных чисел, который помогает выбрать токены, находящиеся дальше усреднённого статистически значения, но даже с ним модель стремится к чему-то статистически среднему. Более того, проблема с этой креативностью в том, что чем дальше LLM уходит от средних значений своего датасета, тем хуже становится её логика, знания деталей и интеллект в целом. Я неоднократно видел, как LLM впадает в "колею" усреднённых шаблонов, и также неоднократно видел, как LLM резко тупеет, если попытаться своими промптами "выбить из колеи", потому что LLM просто не знает, как ей действовать в описанной ситуации. Это, по всей видимости, фундаментальная проблема архитектуры и/или способа тренировки. Креативность людей в этом плане не сильно лучше, но люди хотя бы не деградируют до пускающих слюну дебилов, когда им подбрасывают незнакомую идею и предлагают что-то сочинить с ней: если писатель имеет высокий интеллект, он не потеряет его, попытавшись написать о том, о чём он раньше не писал. Другими словами, креативность LLM хороша только до тех пор, пока ты не познакомился с тем, какие шаблоны поведения заложены в эту конкретную модель конкретным датасетом; как только ты начинаешь узнавать с первого взгляда шаблоны, модель перестаёт казаться креативной, и выбить её из этого состояния без доучивания на неизвестном тебе датасете (или RLHF) просто нереально.
Но это всё не важно. Даже когда ИИ научатся эффективной креативности без потери интеллекта, возвращаемся к тому же аргументу: никто не отбирает у вас ваше воображение, вы можете сами креативить что захотите, вам это никто не запретит, никто не посадит принудительно на кучу веществ, убивающих мышление, не вырежет кусок мозга и т.д. Я думаю, стоит рассматривать ИИ скорее как партнёра по креативности, чем "замену": если раньше люди могли собираться только сами с собой для посиделок с рассказами, теперь любой сможет устроить такие посиделки с ИИ, обмениваясь с ним своими креативностями и получая от этого удовольствие. Разве это не прекрасно? Радоваться надо.
>>098390
Если сделаешь достойную игру, а не очередной безыдейный ассетфлип (чем и являются все клоны уже успешных игр), то никакие кабанычи тебе не страшны, а даже наоборот - если они с тебя скопируют, то игроки пронюхают о существовании твоей игры через их маркетинг. То есть кабан тратит деньги на клон, тратит деньги на маркетинг, а игрок обжигается об его агрессивную монетизацию и ищет альтернативы, в результате чего находя тебя с твоим оригиналом. Просто сам не будь кабаном и люди к тебе потянутся. Конечно, есть нюанс: если кабан заявит на тебя за нарушение авторских прав, автоматическая система торговой площадки может встать на его сторону, и без судебного разбирательства твою игру не вернут. Поэтому нужно качать права первым, а не дожидаться, когда кабан решит устроить чистку конкурентов.
>>098396
Очередной ненужный велосипед с квадратными колёсами от того, кому просто заняться нечем. Лучше бы сделали какой-то более эффективный мост между Godot и другими программами, которые лучше подходят для создания контента. Пока единственная киллер-фича твоей программы в том, что она находится внутри другой программы - у тебя нет киллер-фичи, а значит, твою программу нет смысла скачивать даже бесплатно... Хотя, возможно, такие плагины могут помочь тем, у кого нет доступа к установке нормальных программ на каких-то экзотических платформах. Например, я долгое время перебирал пиксель-арт программы на Android и не нашёл ни одной, которая бы работала совсем без проблем. Если кто-то геймдевит на Godot на Android и хочет пиксель-арт редактор, ему, возможно, будет выгоднее установить плагин на Godot, чем рыться в гугл-помойке в поисках стоящей проги. Но на Windows/Linux и так достаточно программ для рисования, "победить" которые уже нереально.
>>098415
Чего ты там дожидаешься-то? Это для пошаговой игры? С await'ами можно больно выстрелить себе в ногу, если ты забудешь, кто кого ждёт, и прервёшь событие или запустишь его дважды за один раз. Я лично даже не представляю, можно ли как-то легко дебажить await? По моему опыту, Godot позволяет легко посмотреть: состояние дерева, состояние нод, состояние переменных, стек вызовов функций... Но как посмотреть, кто кого в данный момент "ждёт", я не знаю. Это отображается в стеке вызовов?.. Короче, я стараюсь не использовать await без крайней на то необходимости, когда по-другому никак. И при чём тут статические языки? В статических языках тоже бывает понятие "события"/"сигнала"...
>>098420 >>098434
Вы что, кабанчики или гребцы вёслами на галере? Не понимаю вашей паники. Вы так говорите, будто вы всю жизнь вязали одежду на продажу, а потом кабан со швейным станком не просто пришёл, а пришёл, сломал ваши спицы, сжёг клубок ниток и пропихнул закон, уголовно преследующий любого, кто попытается заниматься вязанием одежды вручную. Если вам нравится писать код вручную - никто не обязывает вас юзать нейронки, пишите сколько захотите и чего захотите. Если вам нравится делать игры вручную, с ручным артом и ручным кодом - делайте смело, никто не отберёт у вас инструменты и не прикажет генерировать нейронкой. Вы разводите панику на пустом месте, как будто завтра все компьютеры загорятся и испарятся, а всем людям вживят чипы с принудительным нейрослопом. Даже в случае какого-то глобального катаклизма, останется возможность делать кустарные компьютеры на примитивных транзисторах, программировать их вручную и делать простейшие игры на этом - так что даже в случае апокалипсиса ваши хобби будут довольно защищены от исчезновения. Разве нет?
>>098480
Креативность имеющихся сегодня LLM опирается только на генератор случайных чисел, который помогает выбрать токены, находящиеся дальше усреднённого статистически значения, но даже с ним модель стремится к чему-то статистически среднему. Более того, проблема с этой креативностью в том, что чем дальше LLM уходит от средних значений своего датасета, тем хуже становится её логика, знания деталей и интеллект в целом. Я неоднократно видел, как LLM впадает в "колею" усреднённых шаблонов, и также неоднократно видел, как LLM резко тупеет, если попытаться своими промптами "выбить из колеи", потому что LLM просто не знает, как ей действовать в описанной ситуации. Это, по всей видимости, фундаментальная проблема архитектуры и/или способа тренировки. Креативность людей в этом плане не сильно лучше, но люди хотя бы не деградируют до пускающих слюну дебилов, когда им подбрасывают незнакомую идею и предлагают что-то сочинить с ней: если писатель имеет высокий интеллект, он не потеряет его, попытавшись написать о том, о чём он раньше не писал. Другими словами, креативность LLM хороша только до тех пор, пока ты не познакомился с тем, какие шаблоны поведения заложены в эту конкретную модель конкретным датасетом; как только ты начинаешь узнавать с первого взгляда шаблоны, модель перестаёт казаться креативной, и выбить её из этого состояния без доучивания на неизвестном тебе датасете (или RLHF) просто нереально.
Но это всё не важно. Даже когда ИИ научатся эффективной креативности без потери интеллекта, возвращаемся к тому же аргументу: никто не отбирает у вас ваше воображение, вы можете сами креативить что захотите, вам это никто не запретит, никто не посадит принудительно на кучу веществ, убивающих мышление, не вырежет кусок мозга и т.д. Я думаю, стоит рассматривать ИИ скорее как партнёра по креативности, чем "замену": если раньше люди могли собираться только сами с собой для посиделок с рассказами, теперь любой сможет устроить такие посиделки с ИИ, обмениваясь с ним своими креативностями и получая от этого удовольствие. Разве это не прекрасно? Радоваться надо.
Если сделаешь достойную игру, а не очередной безыдейный ассетфлип (чем и являются все клоны уже успешных игр), то никакие кабанычи тебе не страшны, а даже наоборот - если они с тебя скопируют, то игроки пронюхают о существовании твоей игры через их маркетинг. То есть кабан тратит деньги на клон, тратит деньги на маркетинг, а игрок обжигается об его агрессивную монетизацию и ищет альтернативы, в результате чего находя тебя с твоим оригиналом. Просто сам не будь кабаном и люди к тебе потянутся. Конечно, есть нюанс: если кабан заявит на тебя за нарушение авторских прав, автоматическая система торговой площадки может встать на его сторону, и без судебного разбирательства твою игру не вернут. Поэтому нужно качать права первым, а не дожидаться, когда кабан решит устроить чистку конкурентов.
>>098396
Очередной ненужный велосипед с квадратными колёсами от того, кому просто заняться нечем. Лучше бы сделали какой-то более эффективный мост между Godot и другими программами, которые лучше подходят для создания контента. Пока единственная киллер-фича твоей программы в том, что она находится внутри другой программы - у тебя нет киллер-фичи, а значит, твою программу нет смысла скачивать даже бесплатно... Хотя, возможно, такие плагины могут помочь тем, у кого нет доступа к установке нормальных программ на каких-то экзотических платформах. Например, я долгое время перебирал пиксель-арт программы на Android и не нашёл ни одной, которая бы работала совсем без проблем. Если кто-то геймдевит на Godot на Android и хочет пиксель-арт редактор, ему, возможно, будет выгоднее установить плагин на Godot, чем рыться в гугл-помойке в поисках стоящей проги. Но на Windows/Linux и так достаточно программ для рисования, "победить" которые уже нереально.
>>098415
Чего ты там дожидаешься-то? Это для пошаговой игры? С await'ами можно больно выстрелить себе в ногу, если ты забудешь, кто кого ждёт, и прервёшь событие или запустишь его дважды за один раз. Я лично даже не представляю, можно ли как-то легко дебажить await? По моему опыту, Godot позволяет легко посмотреть: состояние дерева, состояние нод, состояние переменных, стек вызовов функций... Но как посмотреть, кто кого в данный момент "ждёт", я не знаю. Это отображается в стеке вызовов?.. Короче, я стараюсь не использовать await без крайней на то необходимости, когда по-другому никак. И при чём тут статические языки? В статических языках тоже бывает понятие "события"/"сигнала"...
>>098420 >>098434
Вы что, кабанчики или гребцы вёслами на галере? Не понимаю вашей паники. Вы так говорите, будто вы всю жизнь вязали одежду на продажу, а потом кабан со швейным станком не просто пришёл, а пришёл, сломал ваши спицы, сжёг клубок ниток и пропихнул закон, уголовно преследующий любого, кто попытается заниматься вязанием одежды вручную. Если вам нравится писать код вручную - никто не обязывает вас юзать нейронки, пишите сколько захотите и чего захотите. Если вам нравится делать игры вручную, с ручным артом и ручным кодом - делайте смело, никто не отберёт у вас инструменты и не прикажет генерировать нейронкой. Вы разводите панику на пустом месте, как будто завтра все компьютеры загорятся и испарятся, а всем людям вживят чипы с принудительным нейрослопом. Даже в случае какого-то глобального катаклизма, останется возможность делать кустарные компьютеры на примитивных транзисторах, программировать их вручную и делать простейшие игры на этом - так что даже в случае апокалипсиса ваши хобби будут довольно защищены от исчезновения. Разве нет?
>>098480
Креативность имеющихся сегодня LLM опирается только на генератор случайных чисел, который помогает выбрать токены, находящиеся дальше усреднённого статистически значения, но даже с ним модель стремится к чему-то статистически среднему. Более того, проблема с этой креативностью в том, что чем дальше LLM уходит от средних значений своего датасета, тем хуже становится её логика, знания деталей и интеллект в целом. Я неоднократно видел, как LLM впадает в "колею" усреднённых шаблонов, и также неоднократно видел, как LLM резко тупеет, если попытаться своими промптами "выбить из колеи", потому что LLM просто не знает, как ей действовать в описанной ситуации. Это, по всей видимости, фундаментальная проблема архитектуры и/или способа тренировки. Креативность людей в этом плане не сильно лучше, но люди хотя бы не деградируют до пускающих слюну дебилов, когда им подбрасывают незнакомую идею и предлагают что-то сочинить с ней: если писатель имеет высокий интеллект, он не потеряет его, попытавшись написать о том, о чём он раньше не писал. Другими словами, креативность LLM хороша только до тех пор, пока ты не познакомился с тем, какие шаблоны поведения заложены в эту конкретную модель конкретным датасетом; как только ты начинаешь узнавать с первого взгляда шаблоны, модель перестаёт казаться креативной, и выбить её из этого состояния без доучивания на неизвестном тебе датасете (или RLHF) просто нереально.
Но это всё не важно. Даже когда ИИ научатся эффективной креативности без потери интеллекта, возвращаемся к тому же аргументу: никто не отбирает у вас ваше воображение, вы можете сами креативить что захотите, вам это никто не запретит, никто не посадит принудительно на кучу веществ, убивающих мышление, не вырежет кусок мозга и т.д. Я думаю, стоит рассматривать ИИ скорее как партнёра по креативности, чем "замену": если раньше люди могли собираться только сами с собой для посиделок с рассказами, теперь любой сможет устроить такие посиделки с ИИ, обмениваясь с ним своими креативностями и получая от этого удовольствие. Разве это не прекрасно? Радоваться надо.
>>098430
Факт
Факт
>>098549
-Мам, можно мне loop от Боба Нистрома?
-Нет, у нас есть дома корутины!
Я не знаю насколько это практично в дальнейшем, но я бегло написал и пока этого хватает. Корутины не так тяжелы как кажутся, если стейтами не дать их множить в кадре.
-Мам, можно мне loop от Боба Нистрома?
-Нет, у нас есть дома корутины!
Я не знаю насколько это практично в дальнейшем, но я бегло написал и пока этого хватает. Корутины не так тяжелы как кажутся, если стейтами не дать их множить в кадре.
>>098587
Только на нескольких сигналах (нужен WaitGroup).
Дебаг не может нигде (кроме, вроде, языка котлина, но это не точно).
Это лучше читается чем дробить хендлерами по сигналам. Если это не сигналы, то читается ровно так же как видишь. По производительности дешево.
> С await'ами можно больно выстрелить себе в ногу
Только на нескольких сигналах (нужен WaitGroup).
Дебаг не может нигде (кроме, вроде, языка котлина, но это не точно).
Это лучше читается чем дробить хендлерами по сигналам. Если это не сигналы, то читается ровно так же как видишь. По производительности дешево.
>>098630
Да, можно сделать лучше, если бы не кривая система ввода через _unhandled_input(). Это все адаптация из-за него. поныл, но уже привык к продуманности годота, мне еще пасфаендер переписывать, потому что кто-то решил сделать часть API через виртуальный методы, краусавцы
Да, можно сделать лучше, если бы не кривая система ввода через _unhandled_input(). Это все адаптация из-за него. поныл, но уже привык к продуманности годота, мне еще пасфаендер переписывать, потому что кто-то решил сделать часть API через виртуальный методы, краусавцы
>>098587
Какие хобби? Это бизнес. Вопрос в конкуренции. Всё началось с того момента, как люди начали вести осёдлый образ жизни в связи с аграрной революцией. Мужики, живущие в лесу больше рисковали, у них могло не хватать еды зимой и т.д. Из-за этого и с девушками могло быть сложнее познакомиться. Сейчас так вообще какой шанс лесному отшельнику жениться и жить спокойно с семьёй в своей землянке?
Аналогично и со всякими печатными станками. Люди зарабатывали переписыванием книг, а теперь они становятся луддитами.
Но генеративные нейронки это нифига не технологии. Это другой тип получения преимущества в конкуренции. В средневековье, например, можно было бы получить условное гражданство какого-то королевства, чтобы иметь свою землю. Но для этого надо сходить в военный поход и проявить себя. Были ли луддитами те, кто отказывался от этого? Нет! Так же и с нейронками долбанными. Технологий там немного, больше перераспределение власти.
>ваши хобби
Какие хобби? Это бизнес. Вопрос в конкуренции. Всё началось с того момента, как люди начали вести осёдлый образ жизни в связи с аграрной революцией. Мужики, живущие в лесу больше рисковали, у них могло не хватать еды зимой и т.д. Из-за этого и с девушками могло быть сложнее познакомиться. Сейчас так вообще какой шанс лесному отшельнику жениться и жить спокойно с семьёй в своей землянке?
Аналогично и со всякими печатными станками. Люди зарабатывали переписыванием книг, а теперь они становятся луддитами.
Но генеративные нейронки это нифига не технологии. Это другой тип получения преимущества в конкуренции. В средневековье, например, можно было бы получить условное гражданство какого-то королевства, чтобы иметь свою землю. Но для этого надо сходить в военный поход и проявить себя. Были ли луддитами те, кто отказывался от этого? Нет! Так же и с нейронками долбанными. Технологий там немного, больше перераспределение власти.
По поводу @export
Да, вроде сначала удобно, привязал через перетаскивание + Alt и делай что хочешь.
НО
-Как только переименовываешь добавленное через Alt тут же слетает привязка (хотя бы протестили чтоли, ну бага же).
-Если ошибка в коде обновление инспектора прекращается. Вот этот инпут лаг просто раздражает. Ты сохранил, а поля еще нет, потому что там где-то в коде что-то не то (в основном с теми же именами).
-Легко запутаться между Нодой и скриптом (открыта одна нода, открыт скрипт из другой ноды - к этому можно привыкнуть?).
-Иногда просто слетают привязки, хз с чем связанно? наверное с переименованием и "импут лагом" инспектора (мне везет, в общем).
Было бы идеально, но увы.
Единственное к чему пришел для статичных нод, это привязывать через нотацию "$SomeName" в родительском скрипте сцене и потом дергать в потомках через owner. Если что-то меняется то только в одном месте (в родители).
Когда постоянно меняешь ноды (прототипируешь) очень этот nodepath неудобен.
Да, вроде сначала удобно, привязал через перетаскивание + Alt и делай что хочешь.
НО
-Как только переименовываешь добавленное через Alt тут же слетает привязка (хотя бы протестили чтоли, ну бага же).
-Если ошибка в коде обновление инспектора прекращается. Вот этот инпут лаг просто раздражает. Ты сохранил, а поля еще нет, потому что там где-то в коде что-то не то (в основном с теми же именами).
-Легко запутаться между Нодой и скриптом (открыта одна нода, открыт скрипт из другой ноды - к этому можно привыкнуть?).
-Иногда просто слетают привязки, хз с чем связанно? наверное с переименованием и "импут лагом" инспектора (мне везет, в общем).
Было бы идеально, но увы.
Единственное к чему пришел для статичных нод, это привязывать через нотацию "$SomeName" в родительском скрипте сцене и потом дергать в потомках через owner. Если что-то меняется то только в одном месте (в родители).
Когда постоянно меняешь ноды (прототипируешь) очень этот nodepath неудобен.
Нет смысла заниматься геймдевом если не создавать свой билетик из нищеты, остальное просто коуп.
>>098692
Кто не понял
1) В корневой ноде скрипте сцены.
2) В любом ноде по сцене (пофиг на вложенность).
Кто не понял
1) В корневой ноде скрипте сцены.
2) В любом ноде по сцене (пофиг на вложенность).
как думаете когда уже введут функции на подобии что бы просто пишешь
func
shot from pistols
и все что бы сам движок все понимал нахера мне каую то логику писать deal damage if hp туда сюда чето епта что за хуйня отсталая
func
shot from pistols
и все что бы сам движок все понимал нахера мне каую то логику писать deal damage if hp туда сюда чето епта что за хуйня отсталая
>>098728
джва года жду такие функции
джва года жду такие функции
>>098728
Потому что простота хуже воровства
Как только ты захочешь больше контроля и то как пистолет должен стрелять, твоя абстракция потечет как фонтан.
Потому что простота хуже воровства
Как только ты захочешь больше контроля и то как пистолет должен стрелять, твоя абстракция потечет как фонтан.
>>098731
Локальная нейронка бесплатная.
Локальная нейронка бесплатная.
>>098666
После таких слов обычно пишут "дальше не читал", но ладно, так уж и быть, прочитал.
Ты пойми, что геймдев - это дерьмовый бизнес, особенно если ты соло. Многие завидуют, когда видят, как кто-то там на западе заработал сколько-то там сотен тысяч долларов "за один день с релиза" - и они хотят так же, но когда им говоришь - "работай" - они, внезапно, ничего не хотят. Сколько денег тебе нужно на еду, на кров, электричество, запчасти для компа? Сколько нужно для маркетинга, связей с сообществом игроков? Что из ассетов и у кого ты закажешь, чтобы твоя игра не выглядела как поделка 5-летнего ребёнка на скретче? А потом нужно отщипывать проценты от прибыли площадке, издателю, государству, всем остальным промежуточным лицам. И сколько ты планируешь на остаток прожить? Месяц? После нескольких лет работы? С огромным риском не получить ничего, кроме расходов, то есть с риском улететь в глубокий минус. Это не бизнес, а слот-машина, которая заманивает яркими картинками, громкими звуками и обещанием выиграть джекпот, тогда как большинство игроков будут медленно, но верно уходить в минус...
Поэтому рассматривать геймдев как бизнес будут только наивные дураки или те, у кого уже есть надёжный капитал, которым можно рискнуть и который не жалко потерять впустую в случае, если схема не выгорит, потому что у них есть стабильный пассивный заработок, которого хватает на жизнь, т.е. они не рискуют своей жизнью и свободой. А всем остальным, кто живёт от зряплаты до зряплаты, стоит рассматривать геймдев только как хобби - приятное времяпрепровождение, которое вряд ли принесёт что-то кроме расходов. Ты мог бы заниматься рисованием масляными красками без надежды продать картину с аукциона, но вместо этого занимаешься геймдевом без надежды продать игру за миллионы долларов - что то хобби, что это хобби, разницы никакой.
>Какие хобби? Это бизнес.
После таких слов обычно пишут "дальше не читал", но ладно, так уж и быть, прочитал.
Ты пойми, что геймдев - это дерьмовый бизнес, особенно если ты соло. Многие завидуют, когда видят, как кто-то там на западе заработал сколько-то там сотен тысяч долларов "за один день с релиза" - и они хотят так же, но когда им говоришь - "работай" - они, внезапно, ничего не хотят. Сколько денег тебе нужно на еду, на кров, электричество, запчасти для компа? Сколько нужно для маркетинга, связей с сообществом игроков? Что из ассетов и у кого ты закажешь, чтобы твоя игра не выглядела как поделка 5-летнего ребёнка на скретче? А потом нужно отщипывать проценты от прибыли площадке, издателю, государству, всем остальным промежуточным лицам. И сколько ты планируешь на остаток прожить? Месяц? После нескольких лет работы? С огромным риском не получить ничего, кроме расходов, то есть с риском улететь в глубокий минус. Это не бизнес, а слот-машина, которая заманивает яркими картинками, громкими звуками и обещанием выиграть джекпот, тогда как большинство игроков будут медленно, но верно уходить в минус...
Поэтому рассматривать геймдев как бизнес будут только наивные дураки или те, у кого уже есть надёжный капитал, которым можно рискнуть и который не жалко потерять впустую в случае, если схема не выгорит, потому что у них есть стабильный пассивный заработок, которого хватает на жизнь, т.е. они не рискуют своей жизнью и свободой. А всем остальным, кто живёт от зряплаты до зряплаты, стоит рассматривать геймдев только как хобби - приятное времяпрепровождение, которое вряд ли принесёт что-то кроме расходов. Ты мог бы заниматься рисованием масляными красками без надежды продать картину с аукциона, но вместо этого занимаешься геймдевом без надежды продать игру за миллионы долларов - что то хобби, что это хобби, разницы никакой.
>>098692
Неправда, ничего не слетает, в .tscn все ссылки обновляются автоматически.
Лол, а зачем ты сохраняешь код, который испорчен критическими ошибками?
Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
Главное, используй кэширование, как-то так, например:
Тогда ты не будешь дёргать дерево сцены на каждом get_node().
Это не очень подход. Предок становится _ready после всех потомков.
Если ты про GUI, то есть такая фишка, позволяет игнорировать положение нод:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_unique_nodes.html
>>098744
Можно как-то так попробовать:
Но я не уверен, можно ли ждать owner.ready в _ready его потомка...
>Как только переименовываешь тут же слетает привязка
Неправда, ничего не слетает, в .tscn все ссылки обновляются автоматически.
>Если ошибка в коде обновление инспектора прекращается
Лол, а зачем ты сохраняешь код, который испорчен критическими ошибками?
>открыта одна нода, открыт скрипт из другой ноды
Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
>это привязывать через нотацию "$SomeName"
Главное, используй кэширование, как-то так, например:
>@onready var _my_node := $MyNode as MyNodeClass
Тогда ты не будешь дёргать дерево сцены на каждом get_node().
>потом дергать в потомках через owner
Это не очень подход. Предок становится _ready после всех потомков.
>Когда постоянно меняешь ноды (прототипируешь)
Если ты про GUI, то есть такая фишка, позволяет игнорировать положение нод:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_unique_nodes.html
>>098744
>автокомплита нет
Можно как-то так попробовать:
>var _o: MyOwnerClass
>func _ready() -> void:
>_ await owner.ready
>_ _o = owner as MyOwnerClass
Но я не уверен, можно ли ждать owner.ready в _ready его потомка...
>>098692
Неправда, ничего не слетает, в .tscn все ссылки обновляются автоматически.
Лол, а зачем ты сохраняешь код, который испорчен критическими ошибками?
Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
Главное, используй кэширование, как-то так, например:
Тогда ты не будешь дёргать дерево сцены на каждом get_node().
Это не очень подход. Предок становится _ready после всех потомков.
Если ты про GUI, то есть такая фишка, позволяет игнорировать положение нод:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_unique_nodes.html
>>098744
Можно как-то так попробовать:
Но я не уверен, можно ли ждать owner.ready в _ready его потомка...
>Как только переименовываешь тут же слетает привязка
Неправда, ничего не слетает, в .tscn все ссылки обновляются автоматически.
>Если ошибка в коде обновление инспектора прекращается
Лол, а зачем ты сохраняешь код, который испорчен критическими ошибками?
>открыта одна нода, открыт скрипт из другой ноды
Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
>это привязывать через нотацию "$SomeName"
Главное, используй кэширование, как-то так, например:
>@onready var _my_node := $MyNode as MyNodeClass
Тогда ты не будешь дёргать дерево сцены на каждом get_node().
>потом дергать в потомках через owner
Это не очень подход. Предок становится _ready после всех потомков.
>Когда постоянно меняешь ноды (прототипируешь)
Если ты про GUI, то есть такая фишка, позволяет игнорировать положение нод:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_unique_nodes.html
>>098744
>автокомплита нет
Можно как-то так попробовать:
>var _o: MyOwnerClass
>func _ready() -> void:
>_ await owner.ready
>_ _o = owner as MyOwnerClass
Но я не уверен, можно ли ждать owner.ready в _ready его потомка...
>>098728
Что-то такое обычно делается одним из двух способов:
1. Объекты в ООП абстрагируют всё настолько сильно, что тебе достаточно просто "соединить ниточками" несколько крупных блоков и получить желаемое поведение. На этом построены некоторые "визуальные языки", типа Blueprint в UE, геоноды в Blender и т.п. Обычно объекты пишутся программистом, который реализует базовое поведение крупных блоков, а ниточки натягивает дизайнер, который уже определяет, как блоки сочетаются друг с другом в композицию.
2. Domain-Specific Language (DSL): создаётся специальный парсер, который позволяет описывать действия на более естественном языке, скрывая все подробности под капотом интерпретатора. Такое часто можно встретить в визуальных новеллах типа RenPy и движках для текстовых игр, где простой синтаксис более понятен и привычен для писателя, чем для программиста. Программист может дополнять и расширять DSL своими модулями, а уже писатель создаёт композицию.
Теоретически, LLM могла бы использоваться для генерации крупных блоков, которые юзер соединяет ниточками, или для создания/расширения DSL для записи юзером. При условии, что LLM способна выдать надёжный результат, подобные блоки-дополнения были бы более удобным применением LLM, чем если вы генерируете код (вайбкодите) через LLM напрямую. Подумайте: вместо того, чтобы описывать на обычном языке что-то вроде "передвинь пистолет вверх на 50 пикселей сразу после выстрела" и ждать, когда LLM что-то там сгенерирует, вы можете сначала попросить себе универсальный "двигатель объекта" и "стрелятор объектами", а потом соединить ниточками "двигатель" с объектом "пистолет" и "пистолет" со "стрелятором", а потом вбить нужное вам число пикселей в "двигатель", не тратя время на ожидание потенциально багнутого/испорченного кода из LLM. При условии, что все эти блоки, конечно, не содержат багов. Но абстрактный изолированный от всего код LLM должна генерировать более эффективно, чем ту лапшу, которую она стремится сделать, прочитав весь код проекта за раз...
Что-то такое обычно делается одним из двух способов:
1. Объекты в ООП абстрагируют всё настолько сильно, что тебе достаточно просто "соединить ниточками" несколько крупных блоков и получить желаемое поведение. На этом построены некоторые "визуальные языки", типа Blueprint в UE, геоноды в Blender и т.п. Обычно объекты пишутся программистом, который реализует базовое поведение крупных блоков, а ниточки натягивает дизайнер, который уже определяет, как блоки сочетаются друг с другом в композицию.
2. Domain-Specific Language (DSL): создаётся специальный парсер, который позволяет описывать действия на более естественном языке, скрывая все подробности под капотом интерпретатора. Такое часто можно встретить в визуальных новеллах типа RenPy и движках для текстовых игр, где простой синтаксис более понятен и привычен для писателя, чем для программиста. Программист может дополнять и расширять DSL своими модулями, а уже писатель создаёт композицию.
Теоретически, LLM могла бы использоваться для генерации крупных блоков, которые юзер соединяет ниточками, или для создания/расширения DSL для записи юзером. При условии, что LLM способна выдать надёжный результат, подобные блоки-дополнения были бы более удобным применением LLM, чем если вы генерируете код (вайбкодите) через LLM напрямую. Подумайте: вместо того, чтобы описывать на обычном языке что-то вроде "передвинь пистолет вверх на 50 пикселей сразу после выстрела" и ждать, когда LLM что-то там сгенерирует, вы можете сначала попросить себе универсальный "двигатель объекта" и "стрелятор объектами", а потом соединить ниточками "двигатель" с объектом "пистолет" и "пистолет" со "стрелятором", а потом вбить нужное вам число пикселей в "двигатель", не тратя время на ожидание потенциально багнутого/испорченного кода из LLM. При условии, что все эти блоки, конечно, не содержат багов. Но абстрактный изолированный от всего код LLM должна генерировать более эффективно, чем ту лапшу, которую она стремится сделать, прочитав весь код проекта за раз...
>>098728
Что-то такое обычно делается одним из двух способов:
1. Объекты в ООП абстрагируют всё настолько сильно, что тебе достаточно просто "соединить ниточками" несколько крупных блоков и получить желаемое поведение. На этом построены некоторые "визуальные языки", типа Blueprint в UE, геоноды в Blender и т.п. Обычно объекты пишутся программистом, который реализует базовое поведение крупных блоков, а ниточки натягивает дизайнер, который уже определяет, как блоки сочетаются друг с другом в композицию.
2. Domain-Specific Language (DSL): создаётся специальный парсер, который позволяет описывать действия на более естественном языке, скрывая все подробности под капотом интерпретатора. Такое часто можно встретить в визуальных новеллах типа RenPy и движках для текстовых игр, где простой синтаксис более понятен и привычен для писателя, чем для программиста. Программист может дополнять и расширять DSL своими модулями, а уже писатель создаёт композицию.
Теоретически, LLM могла бы использоваться для генерации крупных блоков, которые юзер соединяет ниточками, или для создания/расширения DSL для записи юзером. При условии, что LLM способна выдать надёжный результат, подобные блоки-дополнения были бы более удобным применением LLM, чем если вы генерируете код (вайбкодите) через LLM напрямую. Подумайте: вместо того, чтобы описывать на обычном языке что-то вроде "передвинь пистолет вверх на 50 пикселей сразу после выстрела" и ждать, когда LLM что-то там сгенерирует, вы можете сначала попросить себе универсальный "двигатель объекта" и "стрелятор объектами", а потом соединить ниточками "двигатель" с объектом "пистолет" и "пистолет" со "стрелятором", а потом вбить нужное вам число пикселей в "двигатель", не тратя время на ожидание потенциально багнутого/испорченного кода из LLM. При условии, что все эти блоки, конечно, не содержат багов. Но абстрактный изолированный от всего код LLM должна генерировать более эффективно, чем ту лапшу, которую она стремится сделать, прочитав весь код проекта за раз...
Что-то такое обычно делается одним из двух способов:
1. Объекты в ООП абстрагируют всё настолько сильно, что тебе достаточно просто "соединить ниточками" несколько крупных блоков и получить желаемое поведение. На этом построены некоторые "визуальные языки", типа Blueprint в UE, геоноды в Blender и т.п. Обычно объекты пишутся программистом, который реализует базовое поведение крупных блоков, а ниточки натягивает дизайнер, который уже определяет, как блоки сочетаются друг с другом в композицию.
2. Domain-Specific Language (DSL): создаётся специальный парсер, который позволяет описывать действия на более естественном языке, скрывая все подробности под капотом интерпретатора. Такое часто можно встретить в визуальных новеллах типа RenPy и движках для текстовых игр, где простой синтаксис более понятен и привычен для писателя, чем для программиста. Программист может дополнять и расширять DSL своими модулями, а уже писатель создаёт композицию.
Теоретически, LLM могла бы использоваться для генерации крупных блоков, которые юзер соединяет ниточками, или для создания/расширения DSL для записи юзером. При условии, что LLM способна выдать надёжный результат, подобные блоки-дополнения были бы более удобным применением LLM, чем если вы генерируете код (вайбкодите) через LLM напрямую. Подумайте: вместо того, чтобы описывать на обычном языке что-то вроде "передвинь пистолет вверх на 50 пикселей сразу после выстрела" и ждать, когда LLM что-то там сгенерирует, вы можете сначала попросить себе универсальный "двигатель объекта" и "стрелятор объектами", а потом соединить ниточками "двигатель" с объектом "пистолет" и "пистолет" со "стрелятором", а потом вбить нужное вам число пикселей в "двигатель", не тратя время на ожидание потенциально багнутого/испорченного кода из LLM. При условии, что все эти блоки, конечно, не содержат багов. Но абстрактный изолированный от всего код LLM должна генерировать более эффективно, чем ту лапшу, которую она стремится сделать, прочитав весь код проекта за раз...
>>098775
так же я который с опытом програмирования 2 недели щяс это все прочитавший
так же я который с опытом програмирования 2 недели щяс это все прочитавший
>>098761
Хз что, может автосейв и с этим баги. в эпоху GIT зачем вообще руками сейвить? В общем, даже не хочу разбираться, как-будто можно было для дерева тоже UID придумать, или сделать автозамену nodepath который через доллар.
Где?? Все перерыл.
Знаю, сомнительная штука. Кто-то вообще пользуется? Как-будто хочется пометить либо все либо ничего. Никогда не знаешь что и куда перетащишь или переименуешь (может только с опытом).
Да все равно переменную заводить, проще уже @onreаdy на предка сделать.
Не хватало что-то типа phpDoс/JSDoc где ты редактору можешь указать тип для автокомплита, не вмешиваясь в код, нечто типа
#@var owner: TypeName
>Лол, а зачем ты сохраняешь код, который испорчен критическими ошибками?
Хз что, может автосейв и с этим баги. в эпоху GIT зачем вообще руками сейвить? В общем, даже не хочу разбираться, как-будто можно было для дерева тоже UID придумать, или сделать автозамену nodepath который через доллар.
>Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
Где?? Все перерыл.
>Если ты про GUI, то есть такая фишка, позволяет игнорировать положение нод:
Знаю, сомнительная штука. Кто-то вообще пользуется? Как-будто хочется пометить либо все либо ничего. Никогда не знаешь что и куда перетащишь или переименуешь (может только с опытом).
>Можно как-то так попробовать:
Да все равно переменную заводить, проще уже @onreаdy на предка сделать.
Не хватало что-то типа phpDoс/JSDoc где ты редактору можешь указать тип для автокомплита, не вмешиваясь в код, нечто типа
#@var owner: TypeName
33 Кб, 725x182>>098761
Это? Не совсем то. Он еще дергает окно файловой системы (интересно зачем).
Вот если бы по клику ноды такое было.
>Есть опция, чтобы сразу открывать главный скрипт при переключении вкладок.
Это? Не совсем то. Он еще дергает окно файловой системы (интересно зачем).
Вот если бы по клику ноды такое было.
>>098788
Unique Nodes удобно юзать, когда у тебя что-то вроде:
В прототипе всё это может как-то поменяться или перестроиться, но ты хочешь сохранить ссылку на LineEdit без изменений, потому что там важное поле ввода для чего-то. У тебя есть два способа:
И выбрать ноду в инспекторе. Или поставить галочку на Unique Node и:
В первом случае связь сохраняется, если ты меняешь путь или даже имя самой ноды, а во втором случае связь сохраняется, только если ты меняешь положение/путь до ноды в дереве этой сцены.
>>098792
Ну, обычно у тебя 1 сцена = 1 главный скрипт, а все остальные скрипты являются очень второстепенными/неважными и/или принадлежат отдельным вложенным сценам, которые ты обычно открываешь в новой вкладке, когда тебе хочется как-то их скрипт отредактировать, потому что скрипт завязан на внутренности своей сцены.
Выбор ноды и скрипта в редакторе скриптов не связаны, потому что часто бывает такая ситуация, когда ты должен смотреть на один скрипт и на параметры совершенно другой ноды в сцене. Скажем, SubViewport и Camera2D/3D - они обычно управляются из какого-то постороннего скрипта, а у самих если скрипт и есть, то он не связан с текущей сценой... И если бы редактор каждый раз открывал скрипт какой-то другой по клику на ноду, это было бы дико неудобно, не так ли? Ты можешь открыть нужный скрипт в любой момент по клику на значок "белого листа бумаги" сбоку от ноды, если к этой ноде привязан скрипт.
Unique Nodes удобно юзать, когда у тебя что-то вроде:
>Menu
>_ CenterContainer
>_ _ PanelContainer
>_ _ _ ScrollContainer
>_ _ _ _ VBoxContainer
>_ _ _ _ _ HBoxContainer
>_ _ _ _ _ _ Label
>_ _ _ _ _ _ LineEdit
В прототипе всё это может как-то поменяться или перестроиться, но ты хочешь сохранить ссылку на LineEdit без изменений, потому что там важное поле ввода для чего-то. У тебя есть два способа:
>@export var input_field: LineEdit
И выбрать ноду в инспекторе. Или поставить галочку на Unique Node и:
>@onready var _input_field: LineEdit = $%LineEdit
В первом случае связь сохраняется, если ты меняешь путь или даже имя самой ноды, а во втором случае связь сохраняется, только если ты меняешь положение/путь до ноды в дереве этой сцены.
>>098792
Ну, обычно у тебя 1 сцена = 1 главный скрипт, а все остальные скрипты являются очень второстепенными/неважными и/или принадлежат отдельным вложенным сценам, которые ты обычно открываешь в новой вкладке, когда тебе хочется как-то их скрипт отредактировать, потому что скрипт завязан на внутренности своей сцены.
Выбор ноды и скрипта в редакторе скриптов не связаны, потому что часто бывает такая ситуация, когда ты должен смотреть на один скрипт и на параметры совершенно другой ноды в сцене. Скажем, SubViewport и Camera2D/3D - они обычно управляются из какого-то постороннего скрипта, а у самих если скрипт и есть, то он не связан с текущей сценой... И если бы редактор каждый раз открывал скрипт какой-то другой по клику на ноду, это было бы дико неудобно, не так ли? Ты можешь открыть нужный скрипт в любой момент по клику на значок "белого листа бумаги" сбоку от ноды, если к этой ноде привязан скрипт.
>>098802
ИИшка говорит что редактор следит за переименованием у % (но как она галлюцинирует, ппц, надо это проверять).
Да, со сложным ГУИ это пригодится, согласен (я еще с таким не сталкивался).
Я уже пришел к какой-то гармонии, мне думается сегодня был последний фулл-рефакторинг. Можно уже начать делать игру. Наверно
>В первом случае связь сохраняется, если ты меняешь путь или даже имя самой ноды, а во втором случае связь сохраняется, только если ты меняешь положение/путь до ноды в дереве этой сцены.
ИИшка говорит что редактор следит за переименованием у % (но как она галлюцинирует, ппц, надо это проверять).
Да, со сложным ГУИ это пригодится, согласен (я еще с таким не сталкивался).
>Ну, обычно у тебя
Я уже пришел к какой-то гармонии, мне думается сегодня был последний фулл-рефакторинг. Можно уже начать делать игру. Наверно
>>098758
Не хороший майндсет. Чтобы заработать миллионы, нужно:
а) хорошая игра
б) относительно незанятая ниша или подниша
в) пиар
Естесственно, что если что-то из этого не делать, то шанс получения плохого результата велик. Хотя правда, что для этого нужно действительно много работать. Чтобы отточить гладкость игры до максимума, чтобы проводить тесты на игроках, чтоб задать основное движение по пиару.
Не хороший майндсет. Чтобы заработать миллионы, нужно:
а) хорошая игра
б) относительно незанятая ниша или подниша
в) пиар
Естесственно, что если что-то из этого не делать, то шанс получения плохого результата велик. Хотя правда, что для этого нужно действительно много работать. Чтобы отточить гладкость игры до максимума, чтобы проводить тесты на игроках, чтоб задать основное движение по пиару.
>>098814
Кто делает плохие? Игра должна цеплять. А там пусть хоть зеленые точки на экране.
Всегда есть шанс перевернуть любого титана.
Дорого, у тебя есть только сарафанное радио. Кому-то достаточно наныть на стриме на 200.000$, кому-то придется работать с соцсетями.
дорогу осилит идущий
>а) хорошая игра
Кто делает плохие? Игра должна цеплять. А там пусть хоть зеленые точки на экране.
>б) относительно незанятая ниша или подниша
Всегда есть шанс перевернуть любого титана.
>в) пиар
Дорого, у тебя есть только сарафанное радио. Кому-то достаточно наныть на стриме на 200.000$, кому-то придется работать с соцсетями.
дорогу осилит идущий
>>098810
Бред. Символ "%" - это сокращение от get_node(). Редактор даже не предупреждает тебя, если строка в get_node() приведёт к ошибке в рантайме, то есть он за ней не следит. Ещё раз: ты не должен присваивать "%" к @export, т.к. @export нужен только для указания нод через панель инспектора; если ты хочешь брать ноду через "%", тогда используй @onready вместо @export. Разница критическая - т.к. инициализация @export происходит ещё до _init сцены, а вот инициализация @onready происходит непосредственно перед _ready ноды. Поскольку "%" обращается к дереву, у предка он должен происходить только после всех _ready потомков, т.е. в @onready. Возможно, "%" в @export сейчас работает из-за какого-то нового бага - не помню, чтобы это работало раньше.
>>098814
Слишком абстрактное и субъективное понятие. "Хорошесть" игры складывается из многих сложных, неочевидных вещей, и, к тому же, зависит от выбранной целевой аудитории (которую ты отнёс к "нише", хотя это разные понятия). Ты сам свою игру можешь хоть лучшей в мире считать, но если другие люди с тобой не согласны, ты эту игру почти никому не продашь; в то же время, если тебя самого воротит от своей игры, но ты пытаешься сделать "хорошую игру" для других людей, вряд ли у тебя получится действительно хорошо без серьёзных навыков геймдизайнера.
В общем... Лучше делать так, чтобы твоя игра была для тебя удовольствием. Даже если она не сыщет большой популярности у других людей, ты хотя бы не будешь сильно расстроен из-за этого. Если ты будешь делать игру для других через силу, ты потом вдвойне разочаруешься, когда она окажется никому не нужной.
>редактор следит за переименованием у %
Бред. Символ "%" - это сокращение от get_node(). Редактор даже не предупреждает тебя, если строка в get_node() приведёт к ошибке в рантайме, то есть он за ней не следит. Ещё раз: ты не должен присваивать "%" к @export, т.к. @export нужен только для указания нод через панель инспектора; если ты хочешь брать ноду через "%", тогда используй @onready вместо @export. Разница критическая - т.к. инициализация @export происходит ещё до _init сцены, а вот инициализация @onready происходит непосредственно перед _ready ноды. Поскольку "%" обращается к дереву, у предка он должен происходить только после всех _ready потомков, т.е. в @onready. Возможно, "%" в @export сейчас работает из-за какого-то нового бага - не помню, чтобы это работало раньше.
>>098814
>хорошая игра
Слишком абстрактное и субъективное понятие. "Хорошесть" игры складывается из многих сложных, неочевидных вещей, и, к тому же, зависит от выбранной целевой аудитории (которую ты отнёс к "нише", хотя это разные понятия). Ты сам свою игру можешь хоть лучшей в мире считать, но если другие люди с тобой не согласны, ты эту игру почти никому не продашь; в то же время, если тебя самого воротит от своей игры, но ты пытаешься сделать "хорошую игру" для других людей, вряд ли у тебя получится действительно хорошо без серьёзных навыков геймдизайнера.
В общем... Лучше делать так, чтобы твоя игра была для тебя удовольствием. Даже если она не сыщет большой популярности у других людей, ты хотя бы не будешь сильно расстроен из-за этого. Если ты будешь делать игру для других через силу, ты потом вдвойне разочаруешься, когда она окажется никому не нужной.
>>098856
Не, ну хотя бы 4000 продаж за 10 лет можно насобирать, если постоянно долбиться в это. И если игра хоть немного стоющая.
Этого достаточно для небольшой игры, которую можно за годик сделать.
>когда она окажется никому не нужной
Не, ну хотя бы 4000 продаж за 10 лет можно насобирать, если постоянно долбиться в это. И если игра хоть немного стоющая.
Этого достаточно для небольшой игры, которую можно за годик сделать.
>>098867
Так проще на яндекс пойти там и то больше в месяц выйдет.
Так проще на яндекс пойти там и то больше в месяц выйдет.
>>098867
Ну, если тебя продажи волнуют больше игр - делай как знаешь...
Я вот вообще уже давно не хочу ничего никуда публиковать...
Ну, если тебя продажи волнуют больше игр - делай как знаешь...
Я вот вообще уже давно не хочу ничего никуда публиковать...
>>098856
Ну и зачем этот понос? Ну, проверил - молодец, взял бы просто написал.
Там не просто была приписка что нужно проверить утверждение ИИшки. Нет, надо прям просраться, забрызгать монитор, высрать нечитаемую пасту.
Не только, редактор следит за перемещением и переименованием. Это, вероятно, какая-то попытка победить бестолковый NotePath.
Но вот когда в реальности ты будешь переименовывать ноду со скриптом без самого переименования скрипта? А значит слетят типы, а значит искать зависимость по скриптам (снова Ctrl + Shift + R). В итоге ты приходишь к мысли что вообще не хочешь видить nodepath (или минимизировать его до одного места в сцене).
>Бред. Символ "%"
Ну и зачем этот понос? Ну, проверил - молодец, взял бы просто написал.
Там не просто была приписка что нужно проверить утверждение ИИшки. Нет, надо прям просраться, забрызгать монитор, высрать нечитаемую пасту.
>@export нужен только для указания нод через панель инспектора;
Не только, редактор следит за перемещением и переименованием. Это, вероятно, какая-то попытка победить бестолковый NotePath.
Но вот когда в реальности ты будешь переименовывать ноду со скриптом без самого переименования скрипта? А значит слетят типы, а значит искать зависимость по скриптам (снова Ctrl + Shift + R). В итоге ты приходишь к мысли что вообще не хочешь видить nodepath (или минимизировать его до одного места в сцене).
538 Кб, 893x593прямо щяс украду весь интерфейс игрушки в свою РПГ хехехе тупорылая студия потратила миллионы на разработку этого интерфейса а я его в годоте бесплатно
>>098940
Да чё там рассказывать, даже локально всё лагает и нихуя не работает блять. Пока заставил только бегать прыгать и говно собирать в инвентрь
Да чё там рассказывать, даже локально всё лагает и нихуя не работает блять. Пока заставил только бегать прыгать и говно собирать в инвентрь
>>098944
Ты делаешь мультиплеер так, будто у тебя есть доведённый до релиза синглплеер, и игорьки просили онлайна.
Ты делаешь мультиплеер так, будто у тебя есть доведённый до релиза синглплеер, и игорьки просили онлайна.
>>098955
А хз я replication interval побольше сделал а щас до нуля понизил и збс стало, но анимации все поломанный всё равно, а чё там с предметами и оружием происходит я ваще молчу.
А хз я replication interval побольше сделал а щас до нуля понизил и збс стало, но анимации все поломанный всё равно, а чё там с предметами и оружием происходит я ваще молчу.
>>098878
Ты чё такой злой, пупсик? Тебя кто-то обидел?
Ну, бывало такое, а что? Имя/класс скрипта - это общая категория, типа "Button" - "какая-то там кнопка", тогда как имя ноды - это конкретное имя объекта, типа "Play", "Exit", "Restart", "Vasya", "Stats" и т.д. Имя ноды не должно менять имя скрипта и тем более его класс, потому что у тебя может быть много нод одного класса, но с разными именами и предназначениями.
Ещё можно вспомнить, что из-за того, что у нас пока нет namespace, приходится делать длинные имена классов, а нодам в дереве удобнее иметь короткие имена. Я лично у стандартных нод часто удаляю лишние суффиксы вроде "Container", от которых нет никакого толку для меня, и аналогично поступаю с собственными нодами, если дал им длинное название класса.
Если у тебя там везде указаны типы, то Godot сам тебе укажет на все места, где типы не совпадают. Если не указывает, значит, ты что-то не то делаешь, типа, передаёшь типизированный объект через нетипизированный аргумент функции или вроде того. GDScript по умолчанию нетипизированный и требует усилий для полноценной типизации по всему проекту...
Лично у меня единственной проблемой с переименованием классов GDScript было то, что Godot кэшировал какие-то данные о классах в... не помню, ClassDB, что ли?.. И в результате, если ты два класса переименовал по-быстрому, они могли как-то конфликтовать в РЕДАКТОРЕ, типа редактор сыпался ошибками "это не то, давай другое". Помогал сброс кэша.
Не знаю, что у тебя там за проблемы такие, мне NodePath как-то никогда особо не вредил настолько, чтобы "не хотеть видеть" его. Быть может, это потому, что я довольно быстро привык к основному принципу "call down, signal up"? А ещё я стараюсь хранить все объекты как можно более локально. Поэтому я редко взаимодействую с какими-то сложными NodePath.
>надо прям просраться
Ты чё такой злой, пупсик? Тебя кто-то обидел?
>переименовывать ноду со скриптом без самого переименования скрипта
Ну, бывало такое, а что? Имя/класс скрипта - это общая категория, типа "Button" - "какая-то там кнопка", тогда как имя ноды - это конкретное имя объекта, типа "Play", "Exit", "Restart", "Vasya", "Stats" и т.д. Имя ноды не должно менять имя скрипта и тем более его класс, потому что у тебя может быть много нод одного класса, но с разными именами и предназначениями.
Ещё можно вспомнить, что из-за того, что у нас пока нет namespace, приходится делать длинные имена классов, а нодам в дереве удобнее иметь короткие имена. Я лично у стандартных нод часто удаляю лишние суффиксы вроде "Container", от которых нет никакого толку для меня, и аналогично поступаю с собственными нодами, если дал им длинное название класса.
>А значит слетят типы, а значит искать зависимость по скриптам
Если у тебя там везде указаны типы, то Godot сам тебе укажет на все места, где типы не совпадают. Если не указывает, значит, ты что-то не то делаешь, типа, передаёшь типизированный объект через нетипизированный аргумент функции или вроде того. GDScript по умолчанию нетипизированный и требует усилий для полноценной типизации по всему проекту...
Лично у меня единственной проблемой с переименованием классов GDScript было то, что Godot кэшировал какие-то данные о классах в... не помню, ClassDB, что ли?.. И в результате, если ты два класса переименовал по-быстрому, они могли как-то конфликтовать в РЕДАКТОРЕ, типа редактор сыпался ошибками "это не то, давай другое". Помогал сброс кэша.
>вообще не хочешь видить nodepath
Не знаю, что у тебя там за проблемы такие, мне NodePath как-то никогда особо не вредил настолько, чтобы "не хотеть видеть" его. Быть может, это потому, что я довольно быстро привык к основному принципу "call down, signal up"? А ещё я стараюсь хранить все объекты как можно более локально. Поэтому я редко взаимодействую с какими-то сложными NodePath.
>>098878
Ты чё такой злой, пупсик? Тебя кто-то обидел?
Ну, бывало такое, а что? Имя/класс скрипта - это общая категория, типа "Button" - "какая-то там кнопка", тогда как имя ноды - это конкретное имя объекта, типа "Play", "Exit", "Restart", "Vasya", "Stats" и т.д. Имя ноды не должно менять имя скрипта и тем более его класс, потому что у тебя может быть много нод одного класса, но с разными именами и предназначениями.
Ещё можно вспомнить, что из-за того, что у нас пока нет namespace, приходится делать длинные имена классов, а нодам в дереве удобнее иметь короткие имена. Я лично у стандартных нод часто удаляю лишние суффиксы вроде "Container", от которых нет никакого толку для меня, и аналогично поступаю с собственными нодами, если дал им длинное название класса.
Если у тебя там везде указаны типы, то Godot сам тебе укажет на все места, где типы не совпадают. Если не указывает, значит, ты что-то не то делаешь, типа, передаёшь типизированный объект через нетипизированный аргумент функции или вроде того. GDScript по умолчанию нетипизированный и требует усилий для полноценной типизации по всему проекту...
Лично у меня единственной проблемой с переименованием классов GDScript было то, что Godot кэшировал какие-то данные о классах в... не помню, ClassDB, что ли?.. И в результате, если ты два класса переименовал по-быстрому, они могли как-то конфликтовать в РЕДАКТОРЕ, типа редактор сыпался ошибками "это не то, давай другое". Помогал сброс кэша.
Не знаю, что у тебя там за проблемы такие, мне NodePath как-то никогда особо не вредил настолько, чтобы "не хотеть видеть" его. Быть может, это потому, что я довольно быстро привык к основному принципу "call down, signal up"? А ещё я стараюсь хранить все объекты как можно более локально. Поэтому я редко взаимодействую с какими-то сложными NodePath.
>надо прям просраться
Ты чё такой злой, пупсик? Тебя кто-то обидел?
>переименовывать ноду со скриптом без самого переименования скрипта
Ну, бывало такое, а что? Имя/класс скрипта - это общая категория, типа "Button" - "какая-то там кнопка", тогда как имя ноды - это конкретное имя объекта, типа "Play", "Exit", "Restart", "Vasya", "Stats" и т.д. Имя ноды не должно менять имя скрипта и тем более его класс, потому что у тебя может быть много нод одного класса, но с разными именами и предназначениями.
Ещё можно вспомнить, что из-за того, что у нас пока нет namespace, приходится делать длинные имена классов, а нодам в дереве удобнее иметь короткие имена. Я лично у стандартных нод часто удаляю лишние суффиксы вроде "Container", от которых нет никакого толку для меня, и аналогично поступаю с собственными нодами, если дал им длинное название класса.
>А значит слетят типы, а значит искать зависимость по скриптам
Если у тебя там везде указаны типы, то Godot сам тебе укажет на все места, где типы не совпадают. Если не указывает, значит, ты что-то не то делаешь, типа, передаёшь типизированный объект через нетипизированный аргумент функции или вроде того. GDScript по умолчанию нетипизированный и требует усилий для полноценной типизации по всему проекту...
Лично у меня единственной проблемой с переименованием классов GDScript было то, что Godot кэшировал какие-то данные о классах в... не помню, ClassDB, что ли?.. И в результате, если ты два класса переименовал по-быстрому, они могли как-то конфликтовать в РЕДАКТОРЕ, типа редактор сыпался ошибками "это не то, давай другое". Помогал сброс кэша.
>вообще не хочешь видить nodepath
Не знаю, что у тебя там за проблемы такие, мне NodePath как-то никогда особо не вредил настолько, чтобы "не хотеть видеть" его. Быть может, это потому, что я довольно быстро привык к основному принципу "call down, signal up"? А ещё я стараюсь хранить все объекты как можно более локально. Поэтому я редко взаимодействую с какими-то сложными NodePath.
>>098951
По-моему, одной из великих истин геймдева является то, что если ты хочешь мультиплеер - придётся делать его с самого начала, а синглплеер пришивать к мультиплееру сбоку, через фейковый локальный сервер для одного игрока. Потому что сделать наоборот - мультиплеер на базе работающего синглплеера - всегда намного сложнее, если о мультиплеере изначально никто не задумывался и хотели только "довести до релиза синглплеер". Исключения бывают, но там, скорее всего, пришлось переписывать половину игры с нуля, чтобы накрутить мультиплеер на уже вышедшую игру. Да, делать мультиплеер своей самой первой игрой - не стоит, но если ты всё-таки хочешь мультиплеер, он должен быть с самого начала, когда игры толком ещё нет (одна из сложностей мультиплеерных игр).
>>098956
А ты какие инструменты используешь? Что-то из встроенного в Godot? Документацию читал?
>>098904
Да хоть миллиарды. Выглядит как-то неприятно и неудобно. Делай что-то лучше этого.
>Ты делаешь мультиплеер так, будто у тебя есть доведённый до релиза синглплеер
По-моему, одной из великих истин геймдева является то, что если ты хочешь мультиплеер - придётся делать его с самого начала, а синглплеер пришивать к мультиплееру сбоку, через фейковый локальный сервер для одного игрока. Потому что сделать наоборот - мультиплеер на базе работающего синглплеера - всегда намного сложнее, если о мультиплеере изначально никто не задумывался и хотели только "довести до релиза синглплеер". Исключения бывают, но там, скорее всего, пришлось переписывать половину игры с нуля, чтобы накрутить мультиплеер на уже вышедшую игру. Да, делать мультиплеер своей самой первой игрой - не стоит, но если ты всё-таки хочешь мультиплеер, он должен быть с самого начала, когда игры толком ещё нет (одна из сложностей мультиплеерных игр).
>>098956
А ты какие инструменты используешь? Что-то из встроенного в Godot? Документацию читал?
>>098904
>потратила миллионы на разработку этого интерфейса
Да хоть миллиарды. Выглядит как-то неприятно и неудобно. Делай что-то лучше этого.
>>099008
Ну я через rpc и synchronyzer делаю, думал netfox подключить а он ни в какую работать не хотел.
Ну я через rpc и synchronyzer делаю, думал netfox подключить а он ни в какую работать не хотел.
>>099005
Эти суффиксы даются не от пафоса, а для того чтобы в сотнях классах понять с чем ты сейчас работаешь. Это менеджер, сервис, компонент, хелпер, хендлер, модель/сущность, репа (бд в сингл игре - как тебе такое Илон Маск?) итд.
Отсутствие неймспейсов, хотя бы в рамках скоупа сцен - вообще странно, как-будто авторы кроме демок больше ничего не делали. То что на ноду можно привязать только один скрипт - вообще делает собственные названия скрипта бесполезны. У нас сразу появляется два мира - мир дерева SceneTree и мир скриптов (preload(uid) хоть как-то дает возможность не срать в скоуп имен, тихо намекая делать игру на сервисах). Вот только нахера нам нужно все кроме SceneTree?
И самое страшное, что если появиться скоуп имен, они скорее всего возьмут модули питона, а не неймспейсы шарпов.
Это другое, это не отменяет проблемы. Это скорее подход к взаимодействию между нодами, мы же на этапе организации кода вообще.
Да, сигналы дают контракт (интерфейс) взаимодействия. Но как дебажить, если код становиться настолько сложным что в обработчике сигнала, начинают порождаться свои сигналы? Как быстро понять почему урон копьем в ногу - открывает дверь в таверне?
На самом деле я утрирую, но сигналы приятны опять же для мелких демо игр. Вот тот же turn-base loop на сигналах выглядит мерзко, потому что момент переключения перемешивается с сигналами ожидания анимации - основная базовая логика замешивается с местечковой логикой действия юнита. И все равно нужны состояния, которые надо чекнуть в следующем кадре, тогда к чему вообще эти ивенты, если на состояниях будут проще и мы все равно узнаем все изменения в следующем кадре (ну или я тупой просто, не нашел элегантного решения)
Когда прототипируешь (не до конца еще понимаешь общую картину), постоянно меняешь название и иерархию. Но все равно это быстрее чем на шарпах или, упаси, расте
>удаляю лишние суффиксы вроде "Container
Эти суффиксы даются не от пафоса, а для того чтобы в сотнях классах понять с чем ты сейчас работаешь. Это менеджер, сервис, компонент, хелпер, хендлер, модель/сущность, репа (бд в сингл игре - как тебе такое Илон Маск?) итд.
Отсутствие неймспейсов, хотя бы в рамках скоупа сцен - вообще странно, как-будто авторы кроме демок больше ничего не делали. То что на ноду можно привязать только один скрипт - вообще делает собственные названия скрипта бесполезны. У нас сразу появляется два мира - мир дерева SceneTree и мир скриптов (preload(uid) хоть как-то дает возможность не срать в скоуп имен, тихо намекая делать игру на сервисах). Вот только нахера нам нужно все кроме SceneTree?
И самое страшное, что если появиться скоуп имен, они скорее всего возьмут модули питона, а не неймспейсы шарпов.
>Быть может, это потому, что я довольно быстро привык к основному принципу "call down, signal up"?
Это другое, это не отменяет проблемы. Это скорее подход к взаимодействию между нодами, мы же на этапе организации кода вообще.
Да, сигналы дают контракт (интерфейс) взаимодействия. Но как дебажить, если код становиться настолько сложным что в обработчике сигнала, начинают порождаться свои сигналы? Как быстро понять почему урон копьем в ногу - открывает дверь в таверне?
На самом деле я утрирую, но сигналы приятны опять же для мелких демо игр. Вот тот же turn-base loop на сигналах выглядит мерзко, потому что момент переключения перемешивается с сигналами ожидания анимации - основная базовая логика замешивается с местечковой логикой действия юнита. И все равно нужны состояния, которые надо чекнуть в следующем кадре, тогда к чему вообще эти ивенты, если на состояниях будут проще и мы все равно узнаем все изменения в следующем кадре (ну или я тупой просто, не нашел элегантного решения)
>Не знаю, что у тебя там за проблемы такие, мне NodePath как-то никогда особо не вредил настолько, чтобы "не хотеть видеть" его.
Когда прототипируешь (не до конца еще понимаешь общую картину), постоянно меняешь название и иерархию. Но все равно это быстрее чем на шарпах или, упаси, расте
>>099005
Эти суффиксы даются не от пафоса, а для того чтобы в сотнях классах понять с чем ты сейчас работаешь. Это менеджер, сервис, компонент, хелпер, хендлер, модель/сущность, репа (бд в сингл игре - как тебе такое Илон Маск?) итд.
Отсутствие неймспейсов, хотя бы в рамках скоупа сцен - вообще странно, как-будто авторы кроме демок больше ничего не делали. То что на ноду можно привязать только один скрипт - вообще делает собственные названия скрипта бесполезны. У нас сразу появляется два мира - мир дерева SceneTree и мир скриптов (preload(uid) хоть как-то дает возможность не срать в скоуп имен, тихо намекая делать игру на сервисах). Вот только нахера нам нужно все кроме SceneTree?
И самое страшное, что если появиться скоуп имен, они скорее всего возьмут модули питона, а не неймспейсы шарпов.
Это другое, это не отменяет проблемы. Это скорее подход к взаимодействию между нодами, мы же на этапе организации кода вообще.
Да, сигналы дают контракт (интерфейс) взаимодействия. Но как дебажить, если код становиться настолько сложным что в обработчике сигнала, начинают порождаться свои сигналы? Как быстро понять почему урон копьем в ногу - открывает дверь в таверне?
На самом деле я утрирую, но сигналы приятны опять же для мелких демо игр. Вот тот же turn-base loop на сигналах выглядит мерзко, потому что момент переключения перемешивается с сигналами ожидания анимации - основная базовая логика замешивается с местечковой логикой действия юнита. И все равно нужны состояния, которые надо чекнуть в следующем кадре, тогда к чему вообще эти ивенты, если на состояниях будут проще и мы все равно узнаем все изменения в следующем кадре (ну или я тупой просто, не нашел элегантного решения)
Когда прототипируешь (не до конца еще понимаешь общую картину), постоянно меняешь название и иерархию. Но все равно это быстрее чем на шарпах или, упаси, расте
>удаляю лишние суффиксы вроде "Container
Эти суффиксы даются не от пафоса, а для того чтобы в сотнях классах понять с чем ты сейчас работаешь. Это менеджер, сервис, компонент, хелпер, хендлер, модель/сущность, репа (бд в сингл игре - как тебе такое Илон Маск?) итд.
Отсутствие неймспейсов, хотя бы в рамках скоупа сцен - вообще странно, как-будто авторы кроме демок больше ничего не делали. То что на ноду можно привязать только один скрипт - вообще делает собственные названия скрипта бесполезны. У нас сразу появляется два мира - мир дерева SceneTree и мир скриптов (preload(uid) хоть как-то дает возможность не срать в скоуп имен, тихо намекая делать игру на сервисах). Вот только нахера нам нужно все кроме SceneTree?
И самое страшное, что если появиться скоуп имен, они скорее всего возьмут модули питона, а не неймспейсы шарпов.
>Быть может, это потому, что я довольно быстро привык к основному принципу "call down, signal up"?
Это другое, это не отменяет проблемы. Это скорее подход к взаимодействию между нодами, мы же на этапе организации кода вообще.
Да, сигналы дают контракт (интерфейс) взаимодействия. Но как дебажить, если код становиться настолько сложным что в обработчике сигнала, начинают порождаться свои сигналы? Как быстро понять почему урон копьем в ногу - открывает дверь в таверне?
На самом деле я утрирую, но сигналы приятны опять же для мелких демо игр. Вот тот же turn-base loop на сигналах выглядит мерзко, потому что момент переключения перемешивается с сигналами ожидания анимации - основная базовая логика замешивается с местечковой логикой действия юнита. И все равно нужны состояния, которые надо чекнуть в следующем кадре, тогда к чему вообще эти ивенты, если на состояниях будут проще и мы все равно узнаем все изменения в следующем кадре (ну или я тупой просто, не нашел элегантного решения)
>Не знаю, что у тебя там за проблемы такие, мне NodePath как-то никогда особо не вредил настолько, чтобы "не хотеть видеть" его.
Когда прототипируешь (не до конца еще понимаешь общую картину), постоянно меняешь название и иерархию. Но все равно это быстрее чем на шарпах или, упаси, расте
>>099008
А она есть, эта игра? Чтобы переписать её с нуля?
>>098952
80 процентов продукта это 20 процентов усилий, а оставшиеся 20 процентов продукта это 80 процентов усилий. ©
@monkey чья цитата?
> Исключения бывают, но там, скорее всего, пришлось переписывать половину игры с нуля
А она есть, эта игра? Чтобы переписать её с нуля?
>>098952
> готова процентов на 80
80 процентов продукта это 20 процентов усилий, а оставшиеся 20 процентов продукта это 80 процентов усилий. ©
@monkey чья цитата?
Это вариация принципа Парето, где 80/20 изначально про распределение богатства, а вот про последние 20% продукта как самые трудные — просто расхожая фраза из геймдева и софта без конкретного автора. Часто приписывают кому угодно, от анонимных разработчиков до менеджеров проектов.
@monkey а сколько процентов трудозатрат занимает программный код в современных играх по сравнению со всем остальным контентом типа текстур, моделей, анимаций, звуков?
В современных играх программирование обычно занимает 20-30% от общих трудозатрат команды, остальное уходит на арт, анимации, звуки и дизайн уровней. В инди-проектах на Godot код может весить больше, до 40-50%, потому что один-два человека тянут всё. В ААА процент кода падает ещё ниже, так как студия нанимает сотни художников и аниматоров под один движок.
328 Кб, mp4,268x480, 0:09
>>099035
Код может быть прямо зависеть от игры. Если это какой-то симулятор фактории в римворде, то тебе даже анимировать не захочется, от обилия веселой отладки.
Ты будешь разговаривать с другим инди разработчиком - у вас может быть два совершенно разных опыта. Один будет говорить как трахался с бленд анимацией, другой будет жаловаться как искал причину почему курицы перестают кушать на 4 игровой день.
Код может быть прямо зависеть от игры. Если это какой-то симулятор фактории в римворде, то тебе даже анимировать не захочется, от обилия веселой отладки.
Ты будешь разговаривать с другим инди разработчиком - у вас может быть два совершенно разных опыта. Один будет говорить как трахался с бленд анимацией, другой будет жаловаться как искал причину почему курицы перестают кушать на 4 игровой день.
>>099038
Судя по первому сообщению это очередная онлайн дрочильня эрпогэ. Давай не будем выдумывать крайние случаи.
> Если это какой-то симулятор фактории в римворде
Судя по первому сообщению это очередная онлайн дрочильня эрпогэ. Давай не будем выдумывать крайние случаи.
>>099036
Человек тоже ошибается, умножайте их ответы на 0.6
Человек тоже ошибается, умножайте их ответы на 0.6
Блять безумие. Час пытался задебажить, почему у меня физический объект проваливается чуть-чуть в стену. Причем затревает не всегда, а только под определенным углом, и только на пару пикселей, а потом снова начинает замечать коллизию.
Тут надо заметить, что у стены изначально в редакторе нет коллижн шейпа, у меня там лежит хуйнюшка которая в своем _ready создает нужную форму и подкладывает ее стене (обычный Control, который генерит четыре коллижн шейпы, образующие пустой внутри прямоугольник в форме этого контроля. я это использую чтобы вручную не расставлять все стены, а выставить один квадрат и он автоматически построит "комнату")
Так вот я убрал эту хуйню и поставил коллижн шейпы сразу в редакторе (в точности те же самые, скопировал их из сгенеренных через Remote). Баг пропал.
Я в ахуе, потому что вообще непонятно, почему так. Ставишь форму заранее — все ок, ставишь форму через _ready — проваливается. Я б понял, если бы коллизия совсем проебалась, типа форма не смогла добавиться так поздно, физический движок уже чето запек. Но так ведь он ее вроде как видит, иногда коллизия срабатывает, а иногда нет. Да и до этого у меня characterBody2D бегали по этой хуйне без проблем через move&slide, проблемы начались только когда мне потребовалось трогать test_move и move_and_collide
Хз короче, я сам долбоеб конечно что такое сделал, но результат очень странный
Тут надо заметить, что у стены изначально в редакторе нет коллижн шейпа, у меня там лежит хуйнюшка которая в своем _ready создает нужную форму и подкладывает ее стене (обычный Control, который генерит четыре коллижн шейпы, образующие пустой внутри прямоугольник в форме этого контроля. я это использую чтобы вручную не расставлять все стены, а выставить один квадрат и он автоматически построит "комнату")
Так вот я убрал эту хуйню и поставил коллижн шейпы сразу в редакторе (в точности те же самые, скопировал их из сгенеренных через Remote). Баг пропал.
Я в ахуе, потому что вообще непонятно, почему так. Ставишь форму заранее — все ок, ставишь форму через _ready — проваливается. Я б понял, если бы коллизия совсем проебалась, типа форма не смогла добавиться так поздно, физический движок уже чето запек. Но так ведь он ее вроде как видит, иногда коллизия срабатывает, а иногда нет. Да и до этого у меня characterBody2D бегали по этой хуйне без проблем через move&slide, проблемы начались только когда мне потребовалось трогать test_move и move_and_collide
Хз короче, я сам долбоеб конечно что такое сделал, но результат очень странный
>>099100
Не думаю, что виноват _ready...
>>099092
Попробуй спавнить его чуть выше стены. Обычно нерационально спавнить физические объекты в непосредственной близости от стен и полов - им необходимо некоторое пространство вокруг.
Создание коллизий, добавленных в редакторе, будет, очевидно, раньше твоего кода в _ready, и в некоторых ситуациях, физический движок успевает начать свою работу, прежде чем ты доделаешь свою сцену... Это нормально, просто "процедурная генерация" должна принимать во внимание такие нюансы и не спавнить физические объекты слишком близко друг к другу.
Правда, я обычно в 3D. В 2D физика нестабильнее. Физически "тяжёлым" 2D играм лучше поискать альтернативу, например, Box2D или Rapier2D...
Не думаю, что виноват _ready...
>>099092
>только на пару пикселей
Попробуй спавнить его чуть выше стены. Обычно нерационально спавнить физические объекты в непосредственной близости от стен и полов - им необходимо некоторое пространство вокруг.
>Я б понял, если бы коллизия совсем проебалась
Создание коллизий, добавленных в редакторе, будет, очевидно, раньше твоего кода в _ready, и в некоторых ситуациях, физический движок успевает начать свою работу, прежде чем ты доделаешь свою сцену... Это нормально, просто "процедурная генерация" должна принимать во внимание такие нюансы и не спавнить физические объекты слишком близко друг к другу.
Правда, я обычно в 3D. В 2D физика нестабильнее. Физически "тяжёлым" 2D играм лучше поискать альтернативу, например, Box2D или Rapier2D...
>>099092
Алсо, если тебе не нужна рантайм генерация:
Лучше сделай @tool скрипт, который после нажатия @export_tool_button создаёт (или обновляет) все необходимые тебе коллизии в редакторе. Подобные утилиты эффективнее рантайм генерации - нужные операции выполняются один раз, а не каждый раз.
Релевантное:
https://docs.godotengine.org/en/stable/tutorials/plugins/running_code_in_the_editor.html
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html#export-tool-button
Алсо, если тебе не нужна рантайм генерация:
>обычный Control, который генерит четыре коллижн шейпы, образующие пустой внутри прямоугольник в форме этого контроля. я это использую чтобы вручную не расставлять все стены, а выставить один квадрат и он автоматически построит "комнату"
Лучше сделай @tool скрипт, который после нажатия @export_tool_button создаёт (или обновляет) все необходимые тебе коллизии в редакторе. Подобные утилиты эффективнее рантайм генерации - нужные операции выполняются один раз, а не каждый раз.
Релевантное:
https://docs.godotengine.org/en/stable/tutorials/plugins/running_code_in_the_editor.html
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_exports.html#export-tool-button
>>099030
В дереве сцен иконки цветные, забыл? А на панелях инспектора класс ноды, а не её имя. Вообще, мы же параметр Node.name обсуждаем, при чём тут класс?
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-name
Интерпретатор GDScript - это, вроде бы, один switch, навешивать новые фичи в язык тяжело, а ещё их же поддерживать потом нужно. Неймспейсы становятся необходимы, только когда у тебя буквально тысячи независимых классов-компонентов от независимых провайдеров (а.к.а. разработчиков аддонов), т.е. в большинстве Godot-проектов неймспейсы не нужны.
Эээм, ты вообще хоть что-то делал по туториалам?.. Собственное название скрипта/класс нод нужны для размещения множества нод одного класса в сценах.
Просто не пиши строчку class_name в своих скриптах и пользуйся утиной типизацией, например:
Работает как часы, ноль проблем.
Также существуют "внутренние скрипты" сцен: если добавляешь скрипт нажатием кнопки на ноде, в меню выбирай "внутренний/встроенный" (не помню точно) - полученный скрипт будет безымянным и сохранится непосредственно в .tscn. Одна сцена может иметь неограниченное число таких скриптов. У них вообще невозможно задать class_name, но оно и не нужно. Чрезвычайно годная фича Godot/GDScript, ящитаю.
Это не проблема, пока ты следуешь чётким правилам, которые сам принял и стараешься не нарушать нигде.
Ты делишь шкуру неубитого медведя. Вот когда/если начнутся такие проблемы, тогда и будем их решать... Наверняка выгоришь и забросишь до этих проблем.
Ладно, уговорил, попробую сделать пошаговую...
Ну, так говорили же уже - юзай @export, он всегда отслеживает все изменения в дереве сцены. В 3.x существовал похожий механизм, вроде и сейчас он существует, поэтому у нас есть тип "NodePath", не использующийся толком нигде. Т.е. даже на 3.x не существовало такой уж большой проблемы, а в 4.x сплошное удовольствие работать же...
>чтобы в сотнях классах понять с чем ты сейчас
В дереве сцен иконки цветные, забыл? А на панелях инспектора класс ноды, а не её имя. Вообще, мы же параметр Node.name обсуждаем, при чём тут класс?
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-name
>Отсутствие неймспейсов, хотя бы в рамках скоупа сцен - вообще странно, как-будто авторы кроме демок больше ничего не делали.
Интерпретатор GDScript - это, вроде бы, один switch, навешивать новые фичи в язык тяжело, а ещё их же поддерживать потом нужно. Неймспейсы становятся необходимы, только когда у тебя буквально тысячи независимых классов-компонентов от независимых провайдеров (а.к.а. разработчиков аддонов), т.е. в большинстве Godot-проектов неймспейсы не нужны.
>То что на ноду можно привязать только один скрипт - вообще делает собственные названия скрипта бесполезны.
Эээм, ты вообще хоть что-то делал по туториалам?.. Собственное название скрипта/класс нод нужны для размещения множества нод одного класса в сценах.
>возможность не срать в скоуп имен
Просто не пиши строчку class_name в своих скриптах и пользуйся утиной типизацией, например:
>func _on_object_enter(object: Node):
>_ if "receive_damage" in object:
>_ _ object.receive_damage(damage)
Работает как часы, ноль проблем.
Также существуют "внутренние скрипты" сцен: если добавляешь скрипт нажатием кнопки на ноде, в меню выбирай "внутренний/встроенный" (не помню точно) - полученный скрипт будет безымянным и сохранится непосредственно в .tscn. Одна сцена может иметь неограниченное число таких скриптов. У них вообще невозможно задать class_name, но оно и не нужно. Чрезвычайно годная фича Godot/GDScript, ящитаю.
>Но как дебажить, если код становиться настолько сложным что в обработчике сигнала, начинают порождаться свои сигналы?
Это не проблема, пока ты следуешь чётким правилам, которые сам принял и стараешься не нарушать нигде.
>мы же на этапе организации кода вообще
>Как быстро понять почему урон копьем в ногу - открывает дверь в таверне?
Ты делишь шкуру неубитого медведя. Вот когда/если начнутся такие проблемы, тогда и будем их решать... Наверняка выгоришь и забросишь до этих проблем.
>не нашел элегантного решения
Ладно, уговорил, попробую сделать пошаговую...
>постоянно меняешь название и иерархию
Ну, так говорили же уже - юзай @export, он всегда отслеживает все изменения в дереве сцены. В 3.x существовал похожий механизм, вроде и сейчас он существует, поэтому у нас есть тип "NodePath", не использующийся толком нигде. Т.е. даже на 3.x не существовало такой уж большой проблемы, а в 4.x сплошное удовольствие работать же...
>>099030
В дереве сцен иконки цветные, забыл? А на панелях инспектора класс ноды, а не её имя. Вообще, мы же параметр Node.name обсуждаем, при чём тут класс?
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-name
Интерпретатор GDScript - это, вроде бы, один switch, навешивать новые фичи в язык тяжело, а ещё их же поддерживать потом нужно. Неймспейсы становятся необходимы, только когда у тебя буквально тысячи независимых классов-компонентов от независимых провайдеров (а.к.а. разработчиков аддонов), т.е. в большинстве Godot-проектов неймспейсы не нужны.
Эээм, ты вообще хоть что-то делал по туториалам?.. Собственное название скрипта/класс нод нужны для размещения множества нод одного класса в сценах.
Просто не пиши строчку class_name в своих скриптах и пользуйся утиной типизацией, например:
Работает как часы, ноль проблем.
Также существуют "внутренние скрипты" сцен: если добавляешь скрипт нажатием кнопки на ноде, в меню выбирай "внутренний/встроенный" (не помню точно) - полученный скрипт будет безымянным и сохранится непосредственно в .tscn. Одна сцена может иметь неограниченное число таких скриптов. У них вообще невозможно задать class_name, но оно и не нужно. Чрезвычайно годная фича Godot/GDScript, ящитаю.
Это не проблема, пока ты следуешь чётким правилам, которые сам принял и стараешься не нарушать нигде.
Ты делишь шкуру неубитого медведя. Вот когда/если начнутся такие проблемы, тогда и будем их решать... Наверняка выгоришь и забросишь до этих проблем.
Ладно, уговорил, попробую сделать пошаговую...
Ну, так говорили же уже - юзай @export, он всегда отслеживает все изменения в дереве сцены. В 3.x существовал похожий механизм, вроде и сейчас он существует, поэтому у нас есть тип "NodePath", не использующийся толком нигде. Т.е. даже на 3.x не существовало такой уж большой проблемы, а в 4.x сплошное удовольствие работать же...
>чтобы в сотнях классах понять с чем ты сейчас
В дереве сцен иконки цветные, забыл? А на панелях инспектора класс ноды, а не её имя. Вообще, мы же параметр Node.name обсуждаем, при чём тут класс?
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-property-name
>Отсутствие неймспейсов, хотя бы в рамках скоупа сцен - вообще странно, как-будто авторы кроме демок больше ничего не делали.
Интерпретатор GDScript - это, вроде бы, один switch, навешивать новые фичи в язык тяжело, а ещё их же поддерживать потом нужно. Неймспейсы становятся необходимы, только когда у тебя буквально тысячи независимых классов-компонентов от независимых провайдеров (а.к.а. разработчиков аддонов), т.е. в большинстве Godot-проектов неймспейсы не нужны.
>То что на ноду можно привязать только один скрипт - вообще делает собственные названия скрипта бесполезны.
Эээм, ты вообще хоть что-то делал по туториалам?.. Собственное название скрипта/класс нод нужны для размещения множества нод одного класса в сценах.
>возможность не срать в скоуп имен
Просто не пиши строчку class_name в своих скриптах и пользуйся утиной типизацией, например:
>func _on_object_enter(object: Node):
>_ if "receive_damage" in object:
>_ _ object.receive_damage(damage)
Работает как часы, ноль проблем.
Также существуют "внутренние скрипты" сцен: если добавляешь скрипт нажатием кнопки на ноде, в меню выбирай "внутренний/встроенный" (не помню точно) - полученный скрипт будет безымянным и сохранится непосредственно в .tscn. Одна сцена может иметь неограниченное число таких скриптов. У них вообще невозможно задать class_name, но оно и не нужно. Чрезвычайно годная фича Godot/GDScript, ящитаю.
>Но как дебажить, если код становиться настолько сложным что в обработчике сигнала, начинают порождаться свои сигналы?
Это не проблема, пока ты следуешь чётким правилам, которые сам принял и стараешься не нарушать нигде.
>мы же на этапе организации кода вообще
>Как быстро понять почему урон копьем в ногу - открывает дверь в таверне?
Ты делишь шкуру неубитого медведя. Вот когда/если начнутся такие проблемы, тогда и будем их решать... Наверняка выгоришь и забросишь до этих проблем.
>не нашел элегантного решения
Ладно, уговорил, попробую сделать пошаговую...
>постоянно меняешь название и иерархию
Ну, так говорили же уже - юзай @export, он всегда отслеживает все изменения в дереве сцены. В 3.x существовал похожий механизм, вроде и сейчас он существует, поэтому у нас есть тип "NodePath", не использующийся толком нигде. Т.е. даже на 3.x не существовало такой уж большой проблемы, а в 4.x сплошное удовольствие работать же...
>>099113
Сколько платишь за бета-тест своего вайб-совета?
Нейронка права на счёт депенетрации move_and_slide, однако, остальные советы вырваны из контекста. Но, аноним выше сказал, что если вручную расставить - нормально выходит, т.е. вряд ли нужно делать свой механизм депенетрации. И ему в принципе не нужно размещать свои коллизии прямо в рантайме.
>>099040
Почему РПГ, а не лутер-шутер, например?
>>099035 >>099038
Вы оба правы по-своему. ААА студии делают игры в преимущественно художественном плане, на заранее подготовленном движке, поэтому кода там немного. Индюки делают свою "факторио в римворлде", вот и получается, что кода больше, чем какого-либо арта. Естественно, конкретный "процент кода" невозможно определить, но то, что арт/дизайн в играх зачастую перевешивает любой код - это факт и база.
>Протестируй
Сколько платишь за бета-тест своего вайб-совета?
Нейронка права на счёт депенетрации move_and_slide, однако, остальные советы вырваны из контекста. Но, аноним выше сказал, что если вручную расставить - нормально выходит, т.е. вряд ли нужно делать свой механизм депенетрации. И ему в принципе не нужно размещать свои коллизии прямо в рантайме.
>>099040
>очередная онлайн дрочильня эрпогэ
Почему РПГ, а не лутер-шутер, например?
>>099035 >>099038
Вы оба правы по-своему. ААА студии делают игры в преимущественно художественном плане, на заранее подготовленном движке, поэтому кода там немного. Индюки делают свою "факторио в римворлде", вот и получается, что кода больше, чем какого-либо арта. Естественно, конкретный "процент кода" невозможно определить, но то, что арт/дизайн в играх зачастую перевешивает любой код - это факт и база.
>>099116
Давай, чекну. Там фулл пошаговость (из последних игра stoneshard)
ходит игрок -> ходит мир -> ходит игрок -> ходит мир
>Ладно, уговорил, попробую сделать пошаговую...
Давай, чекну. Там фулл пошаговость (из последних игра stoneshard)
ходит игрок -> ходит мир -> ходит игрок -> ходит мир
>>099122
Только фатальный недостаток такой игры, если задержка хода больше 150-200мс, становится неприятно играть (импут лаг).
То есть
-минимум анимации (ждать анимации это вообще фатальный минус, но иначе расинхрон действий)
-не очень большое число юнитов в расчете (вне вьюпорта вообще бы анимацию отключать и перемещение делать просто global_position = target)
+ ближний бой не такой унылый как в остальных 2D топ даун играх, можно реально какую-то тактику и синергию скиллов сделать (билдостроение/"шахматы" же).
В общем, минимальная возможность для творчества. Возможно поэтому сам стоншард так медленно развивается. Не то чтобы игра мечты, но пока других идей нет.
Только фатальный недостаток такой игры, если задержка хода больше 150-200мс, становится неприятно играть (импут лаг).
То есть
-минимум анимации (ждать анимации это вообще фатальный минус, но иначе расинхрон действий)
-не очень большое число юнитов в расчете (вне вьюпорта вообще бы анимацию отключать и перемещение делать просто global_position = target)
+ ближний бой не такой унылый как в остальных 2D топ даун играх, можно реально какую-то тактику и синергию скиллов сделать (билдостроение/"шахматы" же).
В общем, минимальная возможность для творчества. Возможно поэтому сам стоншард так медленно развивается. Не то чтобы игра мечты, но пока других идей нет.
>>099108
Как ни странно, артефакт происходил не только в самом начале при загрузке, а даже если поставить тело в отдалении и только потом оно через какое-то время коллайдит. Меня это и удивило
>>099112
Уже сделал, да. самое здравое решение, стоило изначально так делать
>>099113
Лень. Объяснение звучит логично, меня просто раскорежило от того, что коллизия ломалась только чуть-чуть, а частично продолжала работать
>успевает начать свою работу, прежде чем ты доделаешь свою сцену
Как ни странно, артефакт происходил не только в самом начале при загрузке, а даже если поставить тело в отдалении и только потом оно через какое-то время коллайдит. Меня это и удивило
>>099112
>Лучше сделай @tool
Уже сделал, да. самое здравое решение, стоило изначально так делать
>>099113
>Протестируй
Лень. Объяснение звучит логично, меня просто раскорежило от того, что коллизия ломалась только чуть-чуть, а частично продолжала работать
>>099113
нелегитимно, это вайб код
нелегитимно, это вайб код
Добавляете значение какого-то параметра по умолчанию в инспектор:
Потом присваиваете это к "приватной" переменной того же класса:
Допустим, что в наше поле в инспекторе введено число "2".
Вопрос: что будет в _something в _ready? 0, 1 или 2?
Правильный ответ: в _something будет 1, а не 2.
Объяснение. Сначала - инициализация:
_something = something_default = 1
Только потом - десериализация:
something_default = 2
Итог: используйте @onready или присваивайте значение в _ready.
>@export var something_default: int = 1
Потом присваиваете это к "приватной" переменной того же класса:
>var _something := something_default
Допустим, что в наше поле в инспекторе введено число "2".
Вопрос: что будет в _something в _ready? 0, 1 или 2?
Правильный ответ: в _something будет 1, а не 2.
Объяснение. Сначала - инициализация:
_something = something_default = 1
Только потом - десериализация:
something_default = 2
Итог: используйте @onready или присваивайте значение в _ready.
238 Кб, 1096x1435>>099275
НЬЮФАГ С НОГИ ЗАЛЕТАЕТ В ТРЕД
@
ДАЖЕ ПОНГ НЕ МОЖЕТ СДЕЛАТЬ САМ
@
ХОЧЕТ ММО-ЛУТЕР-ШУТЕР-РПГ С НУЛЯ
@
ЗАЛИЛ ВЛАЖНЫЕ ФАНТАЗИИ В ЧАТЖПТ
@
ПУК МНЯМ ВРОДЕ ТАК НЕ ПОЛУЧИЦЦА
@
ЫЫЫЫЫ ЧАТЖПТ СКАЗАЛ НИЗЯЯЯ((((
@
ЧЁ ПРАВДА НИЗЗЯЯЯ((( А ПАЧИМУ(((
@
А НУ ПАДСКАЧИЛИ РАЗАБРАЛИ)))
@
И ЧТОБ ПАНЯТНА БЫЛА ОК)))
НЬЮФАГ С НОГИ ЗАЛЕТАЕТ В ТРЕД
@
ДАЖЕ ПОНГ НЕ МОЖЕТ СДЕЛАТЬ САМ
@
ХОЧЕТ ММО-ЛУТЕР-ШУТЕР-РПГ С НУЛЯ
@
ЗАЛИЛ ВЛАЖНЫЕ ФАНТАЗИИ В ЧАТЖПТ
@
ПУК МНЯМ ВРОДЕ ТАК НЕ ПОЛУЧИЦЦА
@
ЫЫЫЫЫ ЧАТЖПТ СКАЗАЛ НИЗЯЯЯ((((
@
ЧЁ ПРАВДА НИЗЗЯЯЯ((( А ПАЧИМУ(((
@
А НУ ПАДСКАЧИЛИ РАЗАБРАЛИ)))
@
И ЧТОБ ПАНЯТНА БЫЛА ОК)))
45 Кб, 745x521>>099285
Я хз какие решения используются в годоте для сети, но в теории ты можешь сам написать любой сетевой протокол (и это довольно не сложно и интересно).
Синий из "Атаки титанов" прав - вы не хотите учиться и лезете все глубже туда, где уже непростительно отсутствие знаний и вы буквально галлюцинируете вместе с нейронкой, потому что она создана лобызать твои хотелки.
Я хз какие решения используются в годоте для сети, но в теории ты можешь сам написать любой сетевой протокол (и это довольно не сложно и интересно).
Синий из "Атаки титанов" прав - вы не хотите учиться и лезете все глубже туда, где уже непростительно отсутствие знаний и вы буквально галлюцинируете вместе с нейронкой, потому что она создана лобызать твои хотелки.
Сделал сабвьюпорт с понижением разрешения. Текст на игровых объектах тоже снизил разрешение и стал нечитаемым, несмотря на то, объекты находятся вне иерархии. Менюшки при этом (которые живут в UI-ноде на пикриле 3) рендерятся нормально в 100% разрешении.
Как правильно это фиксить в реалиях годоти?
Как правильно это фиксить в реалиях годоти?
>>099339
Во-первых, SubViewport обычно используют с галочкой "Own World3D"... То есть подразумевается, что SubViewport рендерит только те объекты, которые размещены в его потомках. Сейчас у тебя, судя по всему, один или оба вьюпорта рендерят то, что им не принадлежит. Хотя на обычные Label это влиять не должно...
https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-property-own-world-3d
Во-вторых, у тебя там случайно не Label3D надписи? Если это они, тогда придётся либо крутить в них настройки, либо как-то переносить их на отдельный слой с высоким разрешением (т.е. отдельный SubViewport чисто для них). А вообще, лучше вместо Label3D юзать обычные Label, которые двигаются с помощью Camera3D.unproject_position(world_point) - тогда будет максимум возможностей с минимум глюков.
https://docs.godotengine.org/en/stable/classes/class_camera3d.html#class-camera3d-method-unproject-position
Во-первых, SubViewport обычно используют с галочкой "Own World3D"... То есть подразумевается, что SubViewport рендерит только те объекты, которые размещены в его потомках. Сейчас у тебя, судя по всему, один или оба вьюпорта рендерят то, что им не принадлежит. Хотя на обычные Label это влиять не должно...
https://docs.godotengine.org/en/stable/classes/class_viewport.html#class-viewport-property-own-world-3d
Во-вторых, у тебя там случайно не Label3D надписи? Если это они, тогда придётся либо крутить в них настройки, либо как-то переносить их на отдельный слой с высоким разрешением (т.е. отдельный SubViewport чисто для них). А вообще, лучше вместо Label3D юзать обычные Label, которые двигаются с помощью Camera3D.unproject_position(world_point) - тогда будет максимум возможностей с минимум глюков.
https://docs.godotengine.org/en/stable/classes/class_camera3d.html#class-camera3d-method-unproject-position
>>099342
Увы, не мой случай - я использую два вьюпорта, ближайший к камере из них с флагом Transparent BG, они должны накладываться друг на друга, камеры у них синхронизированы по трансформу, если врубить собственный 3д ворлд - такой сетап перестает работать.
Да, он самый. Заметил, что надписи ещё и клипают сквозь геометрию.
Пока надумал, что буду пользоваться обычными лейблами и прикреплять их к специальному отдельному канвасу. За Camera3D.unproject_position(world_point) - спасибо.
>Во-первых, SubViewport обычно используют с галочкой "Own World3D"
Увы, не мой случай - я использую два вьюпорта, ближайший к камере из них с флагом Transparent BG, они должны накладываться друг на друга, камеры у них синхронизированы по трансформу, если врубить собственный 3д ворлд - такой сетап перестает работать.
> Во-вторых, у тебя там случайно не Label3D надписи?
Да, он самый. Заметил, что надписи ещё и клипают сквозь геометрию.
Пока надумал, что буду пользоваться обычными лейблами и прикреплять их к специальному отдельному канвасу. За Camera3D.unproject_position(world_point) - спасибо.
>>099346
Вот подробнее про это и сравнение разных вариантов:
https://docs.godotengine.org/en/stable/tutorials/3d/3d_text.html
Ну, как вариант, можно сделать третий SubViewport, у которого разрешение близкое к оригинальному, own_world_3d = true и сложены внутрь все Label3D, которые контролируются через RemoteTransform3D.
Можно выключить depth test, если у тебя камера строго сверху и перекрывать надписи нечем.
У Label3D есть баг, из-за которого они блюрятся на фоне неба, если в настройках камере включить DoF...
>буду пользоваться обычными лейблами
Вот подробнее про это и сравнение разных вариантов:
https://docs.godotengine.org/en/stable/tutorials/3d/3d_text.html
>если врубить собственный 3д ворлд - такой сетап перестает работать
Ну, как вариант, можно сделать третий SubViewport, у которого разрешение близкое к оригинальному, own_world_3d = true и сложены внутрь все Label3D, которые контролируются через RemoteTransform3D.
>клипают сквозь геометрию
Можно выключить depth test, если у тебя камера строго сверху и перекрывать надписи нечем.
У Label3D есть баг, из-за которого они блюрятся на фоне неба, если в настройках камере включить DoF...
>>099340
Узнал, но по криповости (зловещей долины) он напоминает больше атаку титанов.
Не, там все правильно. Если вайбкодя не будет учиться и постигать то что дает нейронка, он отстанет от рациональной части кода и попадет в тупик (остановиться развитие игры, этакий бесконечный лимб с нейродебилом).
>Ты не узнал знаменитый icon.png?..
Узнал, но по криповости (зловещей долины) он напоминает больше атаку титанов.
>У тебя график неправильный же...
Не, там все правильно. Если вайбкодя не будет учиться и постигать то что дает нейронка, он отстанет от рациональной части кода и попадет в тупик (остановиться развитие игры, этакий бесконечный лимб с нейродебилом).
>>099122
Набросал пока хождение по клеточкам с лимитом на радиус хода (если интересно, алгоритм пути - flood fill через рекурсию со счётчиком шагов, это очень легко реализовать), определением препятствий и перепада высот (герой не может зайти на клетку выше, чем его способность к прыжку, но может спрыгнуть ниже). Завтра планирую продолжить. Нужно реализовать врагов и режим атаки, а также GUI для отображения, хотя бы, очереди команд.
Схема хода планируется такая: "позиционирование героев" -> "заполнение очереди атак" -> "подтверждение хода" -> "выполнение очереди атак и контр-атак" -> "перемещение и атаки противников" -> ... Сразу скажу: не я это всё придумал, есть много очень старых игр с такой схемой, просто это база, без которой остальное не заработает, и выдумывать что-то новое в этом жанре мне пока что не хочется (но я уже думаю, как это всё облегчить).
Из более отдалённых планов: сделать генерацию местами гладкого, местами обрывистого ландшафта вместо тех квадратиков на GridMap, что есть сейчас; нарисовать какие-нибудь спрайты героев - хочу попробовать 2.5D стиль, поэтому и использовал icon.png в Sprite3D; накидать классы героев с характеристиками и способностями; сделать центральный штаб и механизм поиска-генерации таких вот мелких карт, а также, естественно, условия проигрыша и победы, выход из локации в штаб, получение новых героев и т.д. - что я уже давно хотел сделать, но не решался.
В прошлом мне хотелось реализовать эту задумку как "геройский шутер" с полноценными 3D моделями, но сейчас пошаговая тактика с 2.5D графикой привлекает больше, как минимум потому, что это мне точно по силам. Если не забью, конечно... Рисовать можно будет по ходу дела подучиться, это не такая уж большая проблема...
Фух, за последние пару дней столько всего в голову полезло из-за одной только мысли сделать такую игру...
Меня больше тянет к жанру "Tactical RPG", наподобие Disgaea, где игрок управляет командой довольно уникальных героев-специалистов по отдельности за один ход, а не одним героем-универсалом. Я не знаю, чего ты так к этому Stoneshard прицепился - по трейлеру там "Open World Survival Craft", а не полноценные "шахматы"...
>>099124
Ты про управление через WASD, когда одно нажатие == ход на одну клетку вбок?
А я вот во многие игры не поиграл бы, если бы не их прикольные анимации...
Чем меньше специалистов, тем меньше "тактики" и больше "вдарь посильнее".
По-моему, всё в точности наоборот - возможностей для творчества больше.
Во-первых, пошаговая игра не требует от игрока быстрой реакции на события, а потому и сама не обязана быстро откликаться, что открывает возможность к созданию анимаций как в настоящих мультиках, например, герой может реально присесть перед прыжком, а не взлетать с места словно ракета - к чему вынуждены прибегать все экшен-игры, чтобы ускорить отклик на ввод; больше прикольных анимаций - больше кайфа от наблюдения за игрой, в которой всегда что-то двигается и происходит, а не как в обычных экшенах, где героям тупо некогда двигаться.
Во-вторых, габариты героев, предметов и способностей не играют никакой роли, т.к. всё происходит на шахматной доске, где всё помещается в одну клетку, двигается и атакует строго по клеткам, что позволяет совместить всякий абсурд в спрайтах, катсценах и анимациях со строгими и понятными правилами, избегая мороки с коллизиями.
В-третьих, пока ты не позволяешь игроку собрать имбу-универсала, ты можешь добавлять в игру большое число специалистов и их специальных способностей, которые игрок может комбинировать, и такие комбинации можно быстро наращивать, потому что все взаимодействия стандартизированы по клеточкам и ходам.
В-четвёртых, тут можно сделать более любопытные вещи с ИИ противников, поскольку им не нужно "кричать и бежать на игрока" как в стандартном экшене - они могут быть умнее или необычнее и не вызывать у игрока недовольства, а у героев игрока может быть куда больше интересных взаимодействий с врагами.
В-пятых, процедурная генерация на клеточном поле в разы проще, и при этом выглядит весьма естественно - ведь ходишь ты по клеточкам, а потому и карта должна быть клеточной - отображать клетки на полу, а вот делать шутер на клеточной и тем более ступенчатой карте было бы странно и некрасиво, при этом тебя никто не ограничивает налепить что-то неклеточное в качестве декоративных препятствий, главное - заполнить клеточки правильно, чтобы правила перехода по клеточкам соблюдались независимо от визуала, что куда проще реализовать, чем коллизии.
В общем, на мой взгляд, это топовый жанр, с нераскрытым потанцевалом, хидден гем, так сказать.
Если не находишь в этом всём фана - лучше не берись за это.
Набросал пока хождение по клеточкам с лимитом на радиус хода (если интересно, алгоритм пути - flood fill через рекурсию со счётчиком шагов, это очень легко реализовать), определением препятствий и перепада высот (герой не может зайти на клетку выше, чем его способность к прыжку, но может спрыгнуть ниже). Завтра планирую продолжить. Нужно реализовать врагов и режим атаки, а также GUI для отображения, хотя бы, очереди команд.
Схема хода планируется такая: "позиционирование героев" -> "заполнение очереди атак" -> "подтверждение хода" -> "выполнение очереди атак и контр-атак" -> "перемещение и атаки противников" -> ... Сразу скажу: не я это всё придумал, есть много очень старых игр с такой схемой, просто это база, без которой остальное не заработает, и выдумывать что-то новое в этом жанре мне пока что не хочется (но я уже думаю, как это всё облегчить).
Из более отдалённых планов: сделать генерацию местами гладкого, местами обрывистого ландшафта вместо тех квадратиков на GridMap, что есть сейчас; нарисовать какие-нибудь спрайты героев - хочу попробовать 2.5D стиль, поэтому и использовал icon.png в Sprite3D; накидать классы героев с характеристиками и способностями; сделать центральный штаб и механизм поиска-генерации таких вот мелких карт, а также, естественно, условия проигрыша и победы, выход из локации в штаб, получение новых героев и т.д. - что я уже давно хотел сделать, но не решался.
В прошлом мне хотелось реализовать эту задумку как "геройский шутер" с полноценными 3D моделями, но сейчас пошаговая тактика с 2.5D графикой привлекает больше, как минимум потому, что это мне точно по силам. Если не забью, конечно... Рисовать можно будет по ходу дела подучиться, это не такая уж большая проблема...
Фух, за последние пару дней столько всего в голову полезло из-за одной только мысли сделать такую игру...
>Там фулл пошаговость
>ходит игрок -> ходит мир
Меня больше тянет к жанру "Tactical RPG", наподобие Disgaea, где игрок управляет командой довольно уникальных героев-специалистов по отдельности за один ход, а не одним героем-универсалом. Я не знаю, чего ты так к этому Stoneshard прицепился - по трейлеру там "Open World Survival Craft", а не полноценные "шахматы"...
>>099124
>если задержка хода больше 150-200мс, становится неприятно играть (импут лаг)
Ты про управление через WASD, когда одно нажатие == ход на одну клетку вбок?
>минимум анимации (ждать анимации это вообще фатальный минус
А я вот во многие игры не поиграл бы, если бы не их прикольные анимации...
>не очень большое число юнитов в расчете
Чем меньше специалистов, тем меньше "тактики" и больше "вдарь посильнее".
>В общем, минимальная возможность для творчества.
По-моему, всё в точности наоборот - возможностей для творчества больше.
Во-первых, пошаговая игра не требует от игрока быстрой реакции на события, а потому и сама не обязана быстро откликаться, что открывает возможность к созданию анимаций как в настоящих мультиках, например, герой может реально присесть перед прыжком, а не взлетать с места словно ракета - к чему вынуждены прибегать все экшен-игры, чтобы ускорить отклик на ввод; больше прикольных анимаций - больше кайфа от наблюдения за игрой, в которой всегда что-то двигается и происходит, а не как в обычных экшенах, где героям тупо некогда двигаться.
Во-вторых, габариты героев, предметов и способностей не играют никакой роли, т.к. всё происходит на шахматной доске, где всё помещается в одну клетку, двигается и атакует строго по клеткам, что позволяет совместить всякий абсурд в спрайтах, катсценах и анимациях со строгими и понятными правилами, избегая мороки с коллизиями.
В-третьих, пока ты не позволяешь игроку собрать имбу-универсала, ты можешь добавлять в игру большое число специалистов и их специальных способностей, которые игрок может комбинировать, и такие комбинации можно быстро наращивать, потому что все взаимодействия стандартизированы по клеточкам и ходам.
В-четвёртых, тут можно сделать более любопытные вещи с ИИ противников, поскольку им не нужно "кричать и бежать на игрока" как в стандартном экшене - они могут быть умнее или необычнее и не вызывать у игрока недовольства, а у героев игрока может быть куда больше интересных взаимодействий с врагами.
В-пятых, процедурная генерация на клеточном поле в разы проще, и при этом выглядит весьма естественно - ведь ходишь ты по клеточкам, а потому и карта должна быть клеточной - отображать клетки на полу, а вот делать шутер на клеточной и тем более ступенчатой карте было бы странно и некрасиво, при этом тебя никто не ограничивает налепить что-то неклеточное в качестве декоративных препятствий, главное - заполнить клеточки правильно, чтобы правила перехода по клеточкам соблюдались независимо от визуала, что куда проще реализовать, чем коллизии.
В общем, на мой взгляд, это топовый жанр, с нераскрытым потанцевалом, хидден гем, так сказать.
>Не то чтобы игра мечты, но пока других идей нет.
Если не находишь в этом всём фана - лучше не берись за это.
>>099122
Набросал пока хождение по клеточкам с лимитом на радиус хода (если интересно, алгоритм пути - flood fill через рекурсию со счётчиком шагов, это очень легко реализовать), определением препятствий и перепада высот (герой не может зайти на клетку выше, чем его способность к прыжку, но может спрыгнуть ниже). Завтра планирую продолжить. Нужно реализовать врагов и режим атаки, а также GUI для отображения, хотя бы, очереди команд.
Схема хода планируется такая: "позиционирование героев" -> "заполнение очереди атак" -> "подтверждение хода" -> "выполнение очереди атак и контр-атак" -> "перемещение и атаки противников" -> ... Сразу скажу: не я это всё придумал, есть много очень старых игр с такой схемой, просто это база, без которой остальное не заработает, и выдумывать что-то новое в этом жанре мне пока что не хочется (но я уже думаю, как это всё облегчить).
Из более отдалённых планов: сделать генерацию местами гладкого, местами обрывистого ландшафта вместо тех квадратиков на GridMap, что есть сейчас; нарисовать какие-нибудь спрайты героев - хочу попробовать 2.5D стиль, поэтому и использовал icon.png в Sprite3D; накидать классы героев с характеристиками и способностями; сделать центральный штаб и механизм поиска-генерации таких вот мелких карт, а также, естественно, условия проигрыша и победы, выход из локации в штаб, получение новых героев и т.д. - что я уже давно хотел сделать, но не решался.
В прошлом мне хотелось реализовать эту задумку как "геройский шутер" с полноценными 3D моделями, но сейчас пошаговая тактика с 2.5D графикой привлекает больше, как минимум потому, что это мне точно по силам. Если не забью, конечно... Рисовать можно будет по ходу дела подучиться, это не такая уж большая проблема...
Фух, за последние пару дней столько всего в голову полезло из-за одной только мысли сделать такую игру...
Меня больше тянет к жанру "Tactical RPG", наподобие Disgaea, где игрок управляет командой довольно уникальных героев-специалистов по отдельности за один ход, а не одним героем-универсалом. Я не знаю, чего ты так к этому Stoneshard прицепился - по трейлеру там "Open World Survival Craft", а не полноценные "шахматы"...
>>099124
Ты про управление через WASD, когда одно нажатие == ход на одну клетку вбок?
А я вот во многие игры не поиграл бы, если бы не их прикольные анимации...
Чем меньше специалистов, тем меньше "тактики" и больше "вдарь посильнее".
По-моему, всё в точности наоборот - возможностей для творчества больше.
Во-первых, пошаговая игра не требует от игрока быстрой реакции на события, а потому и сама не обязана быстро откликаться, что открывает возможность к созданию анимаций как в настоящих мультиках, например, герой может реально присесть перед прыжком, а не взлетать с места словно ракета - к чему вынуждены прибегать все экшен-игры, чтобы ускорить отклик на ввод; больше прикольных анимаций - больше кайфа от наблюдения за игрой, в которой всегда что-то двигается и происходит, а не как в обычных экшенах, где героям тупо некогда двигаться.
Во-вторых, габариты героев, предметов и способностей не играют никакой роли, т.к. всё происходит на шахматной доске, где всё помещается в одну клетку, двигается и атакует строго по клеткам, что позволяет совместить всякий абсурд в спрайтах, катсценах и анимациях со строгими и понятными правилами, избегая мороки с коллизиями.
В-третьих, пока ты не позволяешь игроку собрать имбу-универсала, ты можешь добавлять в игру большое число специалистов и их специальных способностей, которые игрок может комбинировать, и такие комбинации можно быстро наращивать, потому что все взаимодействия стандартизированы по клеточкам и ходам.
В-четвёртых, тут можно сделать более любопытные вещи с ИИ противников, поскольку им не нужно "кричать и бежать на игрока" как в стандартном экшене - они могут быть умнее или необычнее и не вызывать у игрока недовольства, а у героев игрока может быть куда больше интересных взаимодействий с врагами.
В-пятых, процедурная генерация на клеточном поле в разы проще, и при этом выглядит весьма естественно - ведь ходишь ты по клеточкам, а потому и карта должна быть клеточной - отображать клетки на полу, а вот делать шутер на клеточной и тем более ступенчатой карте было бы странно и некрасиво, при этом тебя никто не ограничивает налепить что-то неклеточное в качестве декоративных препятствий, главное - заполнить клеточки правильно, чтобы правила перехода по клеточкам соблюдались независимо от визуала, что куда проще реализовать, чем коллизии.
В общем, на мой взгляд, это топовый жанр, с нераскрытым потанцевалом, хидден гем, так сказать.
Если не находишь в этом всём фана - лучше не берись за это.
Набросал пока хождение по клеточкам с лимитом на радиус хода (если интересно, алгоритм пути - flood fill через рекурсию со счётчиком шагов, это очень легко реализовать), определением препятствий и перепада высот (герой не может зайти на клетку выше, чем его способность к прыжку, но может спрыгнуть ниже). Завтра планирую продолжить. Нужно реализовать врагов и режим атаки, а также GUI для отображения, хотя бы, очереди команд.
Схема хода планируется такая: "позиционирование героев" -> "заполнение очереди атак" -> "подтверждение хода" -> "выполнение очереди атак и контр-атак" -> "перемещение и атаки противников" -> ... Сразу скажу: не я это всё придумал, есть много очень старых игр с такой схемой, просто это база, без которой остальное не заработает, и выдумывать что-то новое в этом жанре мне пока что не хочется (но я уже думаю, как это всё облегчить).
Из более отдалённых планов: сделать генерацию местами гладкого, местами обрывистого ландшафта вместо тех квадратиков на GridMap, что есть сейчас; нарисовать какие-нибудь спрайты героев - хочу попробовать 2.5D стиль, поэтому и использовал icon.png в Sprite3D; накидать классы героев с характеристиками и способностями; сделать центральный штаб и механизм поиска-генерации таких вот мелких карт, а также, естественно, условия проигрыша и победы, выход из локации в штаб, получение новых героев и т.д. - что я уже давно хотел сделать, но не решался.
В прошлом мне хотелось реализовать эту задумку как "геройский шутер" с полноценными 3D моделями, но сейчас пошаговая тактика с 2.5D графикой привлекает больше, как минимум потому, что это мне точно по силам. Если не забью, конечно... Рисовать можно будет по ходу дела подучиться, это не такая уж большая проблема...
Фух, за последние пару дней столько всего в голову полезло из-за одной только мысли сделать такую игру...
>Там фулл пошаговость
>ходит игрок -> ходит мир
Меня больше тянет к жанру "Tactical RPG", наподобие Disgaea, где игрок управляет командой довольно уникальных героев-специалистов по отдельности за один ход, а не одним героем-универсалом. Я не знаю, чего ты так к этому Stoneshard прицепился - по трейлеру там "Open World Survival Craft", а не полноценные "шахматы"...
>>099124
>если задержка хода больше 150-200мс, становится неприятно играть (импут лаг)
Ты про управление через WASD, когда одно нажатие == ход на одну клетку вбок?
>минимум анимации (ждать анимации это вообще фатальный минус
А я вот во многие игры не поиграл бы, если бы не их прикольные анимации...
>не очень большое число юнитов в расчете
Чем меньше специалистов, тем меньше "тактики" и больше "вдарь посильнее".
>В общем, минимальная возможность для творчества.
По-моему, всё в точности наоборот - возможностей для творчества больше.
Во-первых, пошаговая игра не требует от игрока быстрой реакции на события, а потому и сама не обязана быстро откликаться, что открывает возможность к созданию анимаций как в настоящих мультиках, например, герой может реально присесть перед прыжком, а не взлетать с места словно ракета - к чему вынуждены прибегать все экшен-игры, чтобы ускорить отклик на ввод; больше прикольных анимаций - больше кайфа от наблюдения за игрой, в которой всегда что-то двигается и происходит, а не как в обычных экшенах, где героям тупо некогда двигаться.
Во-вторых, габариты героев, предметов и способностей не играют никакой роли, т.к. всё происходит на шахматной доске, где всё помещается в одну клетку, двигается и атакует строго по клеткам, что позволяет совместить всякий абсурд в спрайтах, катсценах и анимациях со строгими и понятными правилами, избегая мороки с коллизиями.
В-третьих, пока ты не позволяешь игроку собрать имбу-универсала, ты можешь добавлять в игру большое число специалистов и их специальных способностей, которые игрок может комбинировать, и такие комбинации можно быстро наращивать, потому что все взаимодействия стандартизированы по клеточкам и ходам.
В-четвёртых, тут можно сделать более любопытные вещи с ИИ противников, поскольку им не нужно "кричать и бежать на игрока" как в стандартном экшене - они могут быть умнее или необычнее и не вызывать у игрока недовольства, а у героев игрока может быть куда больше интересных взаимодействий с врагами.
В-пятых, процедурная генерация на клеточном поле в разы проще, и при этом выглядит весьма естественно - ведь ходишь ты по клеточкам, а потому и карта должна быть клеточной - отображать клетки на полу, а вот делать шутер на клеточной и тем более ступенчатой карте было бы странно и некрасиво, при этом тебя никто не ограничивает налепить что-то неклеточное в качестве декоративных препятствий, главное - заполнить клеточки правильно, чтобы правила перехода по клеточкам соблюдались независимо от визуала, что куда проще реализовать, чем коллизии.
В общем, на мой взгляд, это топовый жанр, с нераскрытым потанцевалом, хидден гем, так сказать.
>Не то чтобы игра мечты, но пока других идей нет.
Если не находишь в этом всём фана - лучше не берись за это.
>>099362
О я тоже пошаговую партийную игру делаю. С оглядкой на rogue trader и divinity. Но масштабы более-менее человеческие и дичь с объектами на клетках творить не могу. У меня визуал локации живёт отдельно, только совпадая с состояниями гексов.
О я тоже пошаговую партийную игру делаю. С оглядкой на rogue trader и divinity. Но масштабы более-менее человеческие и дичь с объектами на клетках творить не могу. У меня визуал локации живёт отдельно, только совпадая с состояниями гексов.
7 Кб, 747x95>>099362
Мы про два разных жанра говорим. Там разная "пошаговость". Пока ты не глянешь игру (она там весит копейки и работает на всем) или стрим, мы не поймем друг друга.
Я в JRPG не играл, но для меня (ИМХО) где есть разделение мира на стратегический геймплей и тактический бой - игры надоедают буквально за пару часов. Может у меня детская травма от героев, но каждый бой это одно и тоже. В тоже время когда действия происходят только на стратегической карте (типа цивы) - тебе не так все угнетает (но это 4х стратегия). Стоншард же показал, что можно сделать хорошую приключенческую (опенворд) игру и передать дух РПГ (а не рогалика, хотя есть эти элементы). Есть тоже множество претензий к игре, но этот вариант даже меня не угнетает так быстро как тактические turn-base.
Почему пошаговость и шахматы - там синергия скиллов и билдострой, от чего решение бросить сетку на одного, и не бить противника со сломанной рукой - может стоит тебе исхода боя. Бои как повторяются так и нет, но они не угнетают точно.
Окей, мне нравится рпг - почему не сделать реалтайм? Ну опять же момент пошаговости - ты не ничего не делаешь - мир ничего не делает (остановился - подумал - покакал), не надо делать игру на тупых стрейфах (игрушка даунов). В такой стиле ближний бой не выглядит убогим (свойство всех 2D top down игр). В общем, как-будто есть потенцевал.
Мы про два разных жанра говорим. Там разная "пошаговость". Пока ты не глянешь игру (она там весит копейки и работает на всем) или стрим, мы не поймем друг друга.
>Я не знаю, чего ты так к этому Stoneshard прицепился
Я в JRPG не играл, но для меня (ИМХО) где есть разделение мира на стратегический геймплей и тактический бой - игры надоедают буквально за пару часов. Может у меня детская травма от героев, но каждый бой это одно и тоже. В тоже время когда действия происходят только на стратегической карте (типа цивы) - тебе не так все угнетает (но это 4х стратегия). Стоншард же показал, что можно сделать хорошую приключенческую (опенворд) игру и передать дух РПГ (а не рогалика, хотя есть эти элементы). Есть тоже множество претензий к игре, но этот вариант даже меня не угнетает так быстро как тактические turn-base.
Почему пошаговость и шахматы - там синергия скиллов и билдострой, от чего решение бросить сетку на одного, и не бить противника со сломанной рукой - может стоит тебе исхода боя. Бои как повторяются так и нет, но они не угнетают точно.
Окей, мне нравится рпг - почему не сделать реалтайм? Ну опять же момент пошаговости - ты не ничего не делаешь - мир ничего не делает (остановился - подумал - покакал), не надо делать игру на тупых стрейфах (игрушка даунов). В такой стиле ближний бой не выглядит убогим (свойство всех 2D top down игр). В общем, как-будто есть потенцевал.
>>099362
Так это проект онли в стол. Я не вижу себя через 1.5 года в стиме (не уверен увижу ли вообще стим). Но мне нравится создавать что-то ради "создования" (да и я не могу фулл-тайм работать).
Я эти два спрайта месяц назад нарисовал под впечатлением от игры и не решался начать (мусолил другую фантазию). Мне думается - опенворд РПГ самый лучших жанр где можно бесконечно аутировать для себя, публиковать идеи (потому что украсть тут нечего). При этом есть 100500 проверенных фич, которыми можно втихую "вдохновиться". Идеально.
>Если не находишь в этом всём фана - лучше не берись за это.
Так это проект онли в стол. Я не вижу себя через 1.5 года в стиме (не уверен увижу ли вообще стим). Но мне нравится создавать что-то ради "создования" (да и я не могу фулл-тайм работать).
Я эти два спрайта месяц назад нарисовал под впечатлением от игры и не решался начать (мусолил другую фантазию). Мне думается - опенворд РПГ самый лучших жанр где можно бесконечно аутировать для себя, публиковать идеи (потому что украсть тут нечего). При этом есть 100500 проверенных фич, которыми можно втихую "вдохновиться". Идеально.
>>099362
Выглядит годно. Но мне кажется тут лучше бы зашли гексы из Endless Legend с ступенчатыми переходами.
Выглядит годно. Но мне кажется тут лучше бы зашли гексы из Endless Legend с ступенчатыми переходами.
Самое сложное в моём первом проекте(дропнут) было сделать туман войны в 2д, а сейчас пятый проект и я также ебусь с туманом, но уже в 3д.
>>099505
Полный туман войны (черная жопа на всю мапу) - самое идиотское наследие РТС. Нужно очень много раз подумать нужен он в текущей игре или нет (иногда правда нужен).
Полный туман войны (черная жопа на всю мапу) - самое идиотское наследие РТС. Нужно очень много раз подумать нужен он в текущей игре или нет (иногда правда нужен).
>>099505
Если твоя карта клеточная - туман несложно сделать.
Если ты не вайбкодя, то опиши свою проблему здесь.
>>099510
Чернота хороша для сеттинга типа Age of Empires. Представь: ты - племя вчерашних пещерных людей, и совершенно ничего не знаешь о мире вокруг пещеры. Постапокалипсис типа Fallout тоже хорошо впишется. Фэнтези пещеры/данжи и подобные штуки - тоже. Но технологически развитой цивилизации, которая тупо захватывает знакомые клочки земли, это не идёт.
Если твоя карта клеточная - туман несложно сделать.
Если ты не вайбкодя, то опиши свою проблему здесь.
>>099510
Чернота хороша для сеттинга типа Age of Empires. Представь: ты - племя вчерашних пещерных людей, и совершенно ничего не знаешь о мире вокруг пещеры. Постапокалипсис типа Fallout тоже хорошо впишется. Фэнтези пещеры/данжи и подобные штуки - тоже. Но технологически развитой цивилизации, которая тупо захватывает знакомые клочки земли, это не идёт.
>>099515
Карта клеточная, но меши в локации живут отдельно от клеток. Условно говоря вместо того чтобы распиливать стену на клетки я делаю целиковый меш и обозначаю клетки как непроходимые.
Карта клеточная, но меши в локации живут отдельно от клеток. Условно говоря вместо того чтобы распиливать стену на клетки я делаю целиковый меш и обозначаю клетки как непроходимые.
307 Кб, 657x722>>099522
нет для своей игры делаю так как рисовать нихуя не умею, а надо иметь 100 нпс разной внешности
идея такую же куклу как в римворлде взять и просто имперсивности добавить, если в голову прилетело катаной спрайты шрамов накидывать или глаз выкололи то закрыть его еще бы волосы научиться рисовать
нет для своей игры делаю так как рисовать нихуя не умею, а надо иметь 100 нпс разной внешности
идея такую же куклу как в римворлде взять и просто имперсивности добавить, если в голову прилетело катаной спрайты шрамов накидывать или глаз выкололи то закрыть его еще бы волосы научиться рисовать
>>099515
Можно показать всю карту, со всеми артефактами, но что происходит там скрыть (этакий серый туман войны). Тогда у игрока сразу образуется план куда и зачем идти. Например тебе нужен ресурс сталь - ты идешь к этой стали. Или видишь что там стали очень много - сразу же воспринимаешь область как стратегически важную. Но что тебя там ждет это уже отдельная тема. Для сетевой игры можно так создавать точки столкновения (да и для AI в сингле так же можно делать). Опять же, раннее пройденная местность скрыта и неожиданно тебя может ждать засада на пути снабжения (если не позаботился о разведке).
А черная задница это черная задница, особенно эти нераскрытые клочки. Но опять же зависит от игры.
Можно показать всю карту, со всеми артефактами, но что происходит там скрыть (этакий серый туман войны). Тогда у игрока сразу образуется план куда и зачем идти. Например тебе нужен ресурс сталь - ты идешь к этой стали. Или видишь что там стали очень много - сразу же воспринимаешь область как стратегически важную. Но что тебя там ждет это уже отдельная тема. Для сетевой игры можно так создавать точки столкновения (да и для AI в сингле так же можно делать). Опять же, раннее пройденная местность скрыта и неожиданно тебя может ждать засада на пути снабжения (если не позаботился о разведке).
А черная задница это черная задница, особенно эти нераскрытые клочки. Но опять же зависит от игры.
>>099519
Длина меча на два тайла - мое почтение.
Если это рим-лайк - смотри что у тебя будет в игре, у тебя слишком мелкие детали, которые пропадут в размерах игры. Но вообще пару раз разместишь в игре поймешь что надо делать.
Длина меча на два тайла - мое почтение.
Если это рим-лайк - смотри что у тебя будет в игре, у тебя слишком мелкие детали, которые пропадут в размерах игры. Но вообще пару раз разместишь в игре поймешь что надо делать.
>>099518
Тогда так: процедурно генерируй меш-стенку, по типу экструзии одной линии - границы видимости - от пола до неба, и накидывай на неё какой-нибудь шейдер.
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
>>099519
Нормально. Лучше сделать кривой плейсхолдер и переделать потом, чем сидеть-потеть над идеальной графикой, а потом обнаружить, что игра не работает.
>>099526
Жопой чувствуешь, что где-то глубоко под землёй в непроходимом лесу есть залежи стали, и все твои противники, даже обезьяны и крокодилы, тоже уже прочувствовали эти залежи и несутся их добывать? Офигенная стратегия, 10 стратегов-эсперов из 10...
Тогда так: процедурно генерируй меш-стенку, по типу экструзии одной линии - границы видимости - от пола до неба, и накидывай на неё какой-нибудь шейдер.
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
>>099519
Нормально. Лучше сделать кривой плейсхолдер и переделать потом, чем сидеть-потеть над идеальной графикой, а потом обнаружить, что игра не работает.
>>099526
>нужен ресурс сталь - ты идешь к этой стали
Жопой чувствуешь, что где-то глубоко под землёй в непроходимом лесу есть залежи стали, и все твои противники, даже обезьяны и крокодилы, тоже уже прочувствовали эти залежи и несутся их добывать? Офигенная стратегия, 10 стратегов-эсперов из 10...
>>099525
Куклы в римки это отдельное умение продать игру с плейсхолдерами. Хочешь визуализировать оторванные ручки ножки, нужны ручки и ножки и тайлы больше 128х128 и вообще добро пожаловать в вектор.
Но хз как там с цензурой стима будет.
Куклы в римки это отдельное умение продать игру с плейсхолдерами. Хочешь визуализировать оторванные ручки ножки, нужны ручки и ножки и тайлы больше 128х128 и вообще добро пожаловать в вектор.
Но хз как там с цензурой стима будет.
>>099531
Неожиданно стратегии это про получение и удержание стратегических ресурсов, а не про приключение или тупой покрас. Чтобы отбить сталь у крокодилов, нужно уже планирование - за что и играют в эти игры - приключение с неизвестной местностью оставь героям меча и говна.
>и несутся их добывать?
Неожиданно стратегии это про получение и удержание стратегических ресурсов, а не про приключение или тупой покрас. Чтобы отбить сталь у крокодилов, нужно уже планирование - за что и играют в эти игры - приключение с неизвестной местностью оставь героям меча и говна.
>>099536
Скорее всего разведотряд частично погибнет об крокодилов. Но тогда ты уже знаешь что эта сталь не так проста и будешь планировать экспедиционный отряд для неё (взвесив за и против, потому что крокодилы требуют солидного отряда и ресурсов).
Так же нужно сразу планировать оборону, потому что об этой стали знаю все! А не только в конце игры и случайно.
Скорее всего разведотряд частично погибнет об крокодилов. Но тогда ты уже знаешь что эта сталь не так проста и будешь планировать экспедиционный отряд для неё (взвесив за и против, потому что крокодилы требуют солидного отряда и ресурсов).
Так же нужно сразу планировать оборону, потому что об этой стали знаю все! А не только в конце игры и случайно.
>>099538
А опытный игрок разместит разведку в лесу, чтобы освещать происходящее в округе и дождётся когда ИИшка частично разобьет отряд крокодилов, сделав тебе половину работы.
Ппц, мы можем в стратегии - использовать стратегию, абалдеть!
А опытный игрок разместит разведку в лесу, чтобы освещать происходящее в округе и дождётся когда ИИшка частично разобьет отряд крокодилов, сделав тебе половину работы.
Ппц, мы можем в стратегии - использовать стратегию, абалдеть!
>>099515
Не мой варик по нескольким причинам сразу, но мы с нейронкой поштурмили эту проблему и вроде как нашли решение, но придётся клетки запекать по колайдерам мешей и туман скорее по клеткам будет работать + хаки чтобы показывать стены не на гексах
> Тогда так: процедурно генерируй меш-стенку
Не мой варик по нескольким причинам сразу, но мы с нейронкой поштурмили эту проблему и вроде как нашли решение, но придётся клетки запекать по колайдерам мешей и туман скорее по клеткам будет работать + хаки чтобы показывать стены не на гексах
>>099390
Пикрил: >>099240
С чего мы вообще начали? "Как сделать ходы для пошаговой игры на нодах и сигналах Godot", нет? Так что поджанр конкретной игры не так уж и важен, пока игра относится к "пошаговым". По-моему, мой вариант даже сложнее будет организовать в коде, чем что-то в стиле классических рогаликов.
Раз так, тогда сыграй в Disgaea DS (35 Мб):
https://archive.org/download/pack-roms-nintendo-ds-eu-usa-jap-rabbits-games/Disgaea%20DS%20%28USA%29.zip
Эмулятор, например, Lemuroid (12 Мб):
https://github.com/Swordfish90/Lemuroid/releases/download/1.15.0/lemuroid-app-free-dynamic-release.apk
Не любишь однообразные комбо?..
Если не делать имбу-универсала, которая может делать что угодно, бои интересны, особенно на процедурных картах, где передвижение ограничено: все тиммейты имеют свои достоинства и недостатки, и приходится думать, кого куда поставить, кем пожертвовать, кого срочно эвакуировать в тыл и т.д. Интересный геймплей, хотя уникального контента в этой версии игры мало. Правда, на сюжетку я забил и копался только в процедурно-случайных локациях "внутри" шмоток (необычная механика прокачки шмоток - найди и побей NPC, чтобы разблокировать бонус). Собственно, меня вдохновили на этот проект именно эти случайные локации.
Лучше в Elin сыграй - контента и механик точно больше. Лучше всего начинать играть вслепую и разбираться самостоятельно, иначе испортишь удовольствие.
Мне кажется, ты что-то путаешь. Жанр rogue-like - это в первую очередь RPG, во вторую очередь dungeon crawler, а уже потом - процедурная генерация и т.п.
>>099397
Помню, видел твои посты где-то.
На мой взгляд, главный недостаток "опенворлда" в том, что ты вынужден заполнить большую карту бесполезным для игрока филлером, который игрок хочет поскорее скипнуть с помощью фаст-тревела или телепортации, и добавлять на эту огромную карту новые точки интереса сложно. Почему бы не вырезать весь филлер, оставив только точки интереса, которые игрок может выбрать из меню и перейти сразу к главному блюду игры? Да, это не будет "опенворлдом", потому что игра делится на "комнаты", но так ведь только лучше для игрока. Игре необходим опенворлд тогда и только тогда, когда перемещение по полям, горам и морям - самое главное. А когда эти поля, горы и моря вызывают лишь раздражение и скуку, то зачем они?
>>099401
Я пробовал делать такое несколько лет назад, и мне не понравилось. Да, гексы позволяют двигаться в любом направлении "честно", с равной скоростью, но они добавляют слишком много головной боли в математику координатной системы, в левел-дизайн, в понимание игроком игровых правил и т.д.
Для карт я планирую что-то ближе к комнатам, коридорам и мостам, которые удобнее собирать из квадратных тайлов и заготовленных сцен-шаблонов.
>>099370
Что ты имеешь в виду под "масштабами"?
>Мы про два разных жанра говорим...
Пикрил: >>099240
С чего мы вообще начали? "Как сделать ходы для пошаговой игры на нодах и сигналах Godot", нет? Так что поджанр конкретной игры не так уж и важен, пока игра относится к "пошаговым". По-моему, мой вариант даже сложнее будет организовать в коде, чем что-то в стиле классических рогаликов.
>Я в JRPG не играл
>Пока ты не глянешь игру
>она там весит копейки и работает на всем
Раз так, тогда сыграй в Disgaea DS (35 Мб):
https://archive.org/download/pack-roms-nintendo-ds-eu-usa-jap-rabbits-games/Disgaea%20DS%20%28USA%29.zip
Эмулятор, например, Lemuroid (12 Мб):
https://github.com/Swordfish90/Lemuroid/releases/download/1.15.0/lemuroid-app-free-dynamic-release.apk
>каждый бой это одно и тоже
Не любишь однообразные комбо?..
Если не делать имбу-универсала, которая может делать что угодно, бои интересны, особенно на процедурных картах, где передвижение ограничено: все тиммейты имеют свои достоинства и недостатки, и приходится думать, кого куда поставить, кем пожертвовать, кого срочно эвакуировать в тыл и т.д. Интересный геймплей, хотя уникального контента в этой версии игры мало. Правда, на сюжетку я забил и копался только в процедурно-случайных локациях "внутри" шмоток (необычная механика прокачки шмоток - найди и побей NPC, чтобы разблокировать бонус). Собственно, меня вдохновили на этот проект именно эти случайные локации.
>Стоншард же показал, что можно сделать...
Лучше в Elin сыграй - контента и механик точно больше. Лучше всего начинать играть вслепую и разбираться самостоятельно, иначе испортишь удовольствие.
>передать дух РПГ, а не рогалика
Мне кажется, ты что-то путаешь. Жанр rogue-like - это в первую очередь RPG, во вторую очередь dungeon crawler, а уже потом - процедурная генерация и т.п.
>>099397
>Я эти два спрайта месяц назад нарисовал
Помню, видел твои посты где-то.
>Мне думается - опенворд РПГ самый лучших жанр где можно бесконечно аутировать
На мой взгляд, главный недостаток "опенворлда" в том, что ты вынужден заполнить большую карту бесполезным для игрока филлером, который игрок хочет поскорее скипнуть с помощью фаст-тревела или телепортации, и добавлять на эту огромную карту новые точки интереса сложно. Почему бы не вырезать весь филлер, оставив только точки интереса, которые игрок может выбрать из меню и перейти сразу к главному блюду игры? Да, это не будет "опенворлдом", потому что игра делится на "комнаты", но так ведь только лучше для игрока. Игре необходим опенворлд тогда и только тогда, когда перемещение по полям, горам и морям - самое главное. А когда эти поля, горы и моря вызывают лишь раздражение и скуку, то зачем они?
>>099401
>гексы из Endless Legend с ступенчатыми переходами
Я пробовал делать такое несколько лет назад, и мне не понравилось. Да, гексы позволяют двигаться в любом направлении "честно", с равной скоростью, но они добавляют слишком много головной боли в математику координатной системы, в левел-дизайн, в понимание игроком игровых правил и т.д.
Для карт я планирую что-то ближе к комнатам, коридорам и мостам, которые удобнее собирать из квадратных тайлов и заготовленных сцен-шаблонов.
>>099370
>Но масштабы более-менее человеческие
Что ты имеешь в виду под "масштабами"?
>>099390
Пикрил: >>099240
С чего мы вообще начали? "Как сделать ходы для пошаговой игры на нодах и сигналах Godot", нет? Так что поджанр конкретной игры не так уж и важен, пока игра относится к "пошаговым". По-моему, мой вариант даже сложнее будет организовать в коде, чем что-то в стиле классических рогаликов.
Раз так, тогда сыграй в Disgaea DS (35 Мб):
https://archive.org/download/pack-roms-nintendo-ds-eu-usa-jap-rabbits-games/Disgaea%20DS%20%28USA%29.zip
Эмулятор, например, Lemuroid (12 Мб):
https://github.com/Swordfish90/Lemuroid/releases/download/1.15.0/lemuroid-app-free-dynamic-release.apk
Не любишь однообразные комбо?..
Если не делать имбу-универсала, которая может делать что угодно, бои интересны, особенно на процедурных картах, где передвижение ограничено: все тиммейты имеют свои достоинства и недостатки, и приходится думать, кого куда поставить, кем пожертвовать, кого срочно эвакуировать в тыл и т.д. Интересный геймплей, хотя уникального контента в этой версии игры мало. Правда, на сюжетку я забил и копался только в процедурно-случайных локациях "внутри" шмоток (необычная механика прокачки шмоток - найди и побей NPC, чтобы разблокировать бонус). Собственно, меня вдохновили на этот проект именно эти случайные локации.
Лучше в Elin сыграй - контента и механик точно больше. Лучше всего начинать играть вслепую и разбираться самостоятельно, иначе испортишь удовольствие.
Мне кажется, ты что-то путаешь. Жанр rogue-like - это в первую очередь RPG, во вторую очередь dungeon crawler, а уже потом - процедурная генерация и т.п.
>>099397
Помню, видел твои посты где-то.
На мой взгляд, главный недостаток "опенворлда" в том, что ты вынужден заполнить большую карту бесполезным для игрока филлером, который игрок хочет поскорее скипнуть с помощью фаст-тревела или телепортации, и добавлять на эту огромную карту новые точки интереса сложно. Почему бы не вырезать весь филлер, оставив только точки интереса, которые игрок может выбрать из меню и перейти сразу к главному блюду игры? Да, это не будет "опенворлдом", потому что игра делится на "комнаты", но так ведь только лучше для игрока. Игре необходим опенворлд тогда и только тогда, когда перемещение по полям, горам и морям - самое главное. А когда эти поля, горы и моря вызывают лишь раздражение и скуку, то зачем они?
>>099401
Я пробовал делать такое несколько лет назад, и мне не понравилось. Да, гексы позволяют двигаться в любом направлении "честно", с равной скоростью, но они добавляют слишком много головной боли в математику координатной системы, в левел-дизайн, в понимание игроком игровых правил и т.д.
Для карт я планирую что-то ближе к комнатам, коридорам и мостам, которые удобнее собирать из квадратных тайлов и заготовленных сцен-шаблонов.
>>099370
Что ты имеешь в виду под "масштабами"?
>Мы про два разных жанра говорим...
Пикрил: >>099240
С чего мы вообще начали? "Как сделать ходы для пошаговой игры на нодах и сигналах Godot", нет? Так что поджанр конкретной игры не так уж и важен, пока игра относится к "пошаговым". По-моему, мой вариант даже сложнее будет организовать в коде, чем что-то в стиле классических рогаликов.
>Я в JRPG не играл
>Пока ты не глянешь игру
>она там весит копейки и работает на всем
Раз так, тогда сыграй в Disgaea DS (35 Мб):
https://archive.org/download/pack-roms-nintendo-ds-eu-usa-jap-rabbits-games/Disgaea%20DS%20%28USA%29.zip
Эмулятор, например, Lemuroid (12 Мб):
https://github.com/Swordfish90/Lemuroid/releases/download/1.15.0/lemuroid-app-free-dynamic-release.apk
>каждый бой это одно и тоже
Не любишь однообразные комбо?..
Если не делать имбу-универсала, которая может делать что угодно, бои интересны, особенно на процедурных картах, где передвижение ограничено: все тиммейты имеют свои достоинства и недостатки, и приходится думать, кого куда поставить, кем пожертвовать, кого срочно эвакуировать в тыл и т.д. Интересный геймплей, хотя уникального контента в этой версии игры мало. Правда, на сюжетку я забил и копался только в процедурно-случайных локациях "внутри" шмоток (необычная механика прокачки шмоток - найди и побей NPC, чтобы разблокировать бонус). Собственно, меня вдохновили на этот проект именно эти случайные локации.
>Стоншард же показал, что можно сделать...
Лучше в Elin сыграй - контента и механик точно больше. Лучше всего начинать играть вслепую и разбираться самостоятельно, иначе испортишь удовольствие.
>передать дух РПГ, а не рогалика
Мне кажется, ты что-то путаешь. Жанр rogue-like - это в первую очередь RPG, во вторую очередь dungeon crawler, а уже потом - процедурная генерация и т.п.
>>099397
>Я эти два спрайта месяц назад нарисовал
Помню, видел твои посты где-то.
>Мне думается - опенворд РПГ самый лучших жанр где можно бесконечно аутировать
На мой взгляд, главный недостаток "опенворлда" в том, что ты вынужден заполнить большую карту бесполезным для игрока филлером, который игрок хочет поскорее скипнуть с помощью фаст-тревела или телепортации, и добавлять на эту огромную карту новые точки интереса сложно. Почему бы не вырезать весь филлер, оставив только точки интереса, которые игрок может выбрать из меню и перейти сразу к главному блюду игры? Да, это не будет "опенворлдом", потому что игра делится на "комнаты", но так ведь только лучше для игрока. Игре необходим опенворлд тогда и только тогда, когда перемещение по полям, горам и морям - самое главное. А когда эти поля, горы и моря вызывают лишь раздражение и скуку, то зачем они?
>>099401
>гексы из Endless Legend с ступенчатыми переходами
Я пробовал делать такое несколько лет назад, и мне не понравилось. Да, гексы позволяют двигаться в любом направлении "честно", с равной скоростью, но они добавляют слишком много головной боли в математику координатной системы, в левел-дизайн, в понимание игроком игровых правил и т.д.
Для карт я планирую что-то ближе к комнатам, коридорам и мостам, которые удобнее собирать из квадратных тайлов и заготовленных сцен-шаблонов.
>>099370
>Но масштабы более-менее человеческие
Что ты имеешь в виду под "масштабами"?
>>099567
Как раз таки нет, потому что в фулл пошаговой надо ждать все анимации, а это еще спагетти из сигналов (на которые ты должен был нарваться сам в процессе, но увы ты сделал вообще другое).
Да и речь не была меряться письками вида сложно не сложно, любая turn-base основа делается за час. Я хотел чтобы ты прочувствовал как херова размазывать логику по сигналам (особенно эти мелкие анимации).
> По-моему, мой вариант даже сложнее будет организовать в коде, чем что-то в стиле классических
Как раз таки нет, потому что в фулл пошаговой надо ждать все анимации, а это еще спагетти из сигналов (на которые ты должен был нарваться сам в процессе, но увы ты сделал вообще другое).
Да и речь не была меряться письками вида сложно не сложно, любая turn-base основа делается за час. Я хотел чтобы ты прочувствовал как херова размазывать логику по сигналам (особенно эти мелкие анимации).
>>099567
Непонятно что они добавляют, есть же "тот" сайт который все с гексами разбирает (даже много лишнего). Ты по сути как с тайлами работаешь, только с гексами - (один раз обертку написал и больше с точными координатами вообще не работаешь, только с нумерацией TileMapLayer и быть может соседями)
>Я пробовал делать такое несколько лет назад, и мне не понравилось. Да, гексы позволяют двигаться в любом направлении "честно", с равной скоростью, но они добавляют слишком много головной боли в математику координатной системы
Непонятно что они добавляют, есть же "тот" сайт который все с гексами разбирает (даже много лишнего). Ты по сути как с тайлами работаешь, только с гексами - (один раз обертку написал и больше с точными координатами вообще не работаешь, только с нумерацией TileMapLayer и быть может соседями)
>>099578
Соседи для odd-r, он же (HEXAGON STACKED в годоте)
https://www.redblobgames.com/grids/hexagons/#coordinates-offset
>"тот" сайт
Соседи для odd-r, он же (HEXAGON STACKED в годоте)
https://www.redblobgames.com/grids/hexagons/#coordinates-offset
39 Кб, 590x517>>099579
Там в соседнем треде вайбкодя носиться с изометрией,
>>1099523 →
Но такое ощущение (судя по видео) что нейронка про соседей в изометрии ему ничего не говорит. А они там тоже не так просто вычисляются (так же зависят от четности "y", если это ISOMETRIC STACKED).
Там в соседнем треде вайбкодя носиться с изометрией,
>>1099523 →
Но такое ощущение (судя по видео) что нейронка про соседей в изометрии ему ничего не говорит. А они там тоже не так просто вычисляются (так же зависят от четности "y", если это ISOMETRIC STACKED).
9,6 Мб, mp4,1280x720, 2:06
>>097332 (OP)
Принес геймплейную идею в тред. Вдруг кому-то пригодится. Значит смотрите. Идея подойдёт к играм в жанрах песочниц и рпг. Если у вас есть различная пища в мире игры, то в какой-то момент развития персонажа она превращается в мусор, забивающий инвентарь, потому что игрок либо лечится шприцами в нф-сеттингах, либо зельями/магией в фентези и ему нет смысла есть все эти ягоды, корешки, грибочки, хлеб, мясо, сыр.
Вопрос. Как решить эту проблему?
Многие разрабы вводят систему потребностей, превращая персонажа в тамагочи. Фи.
И тут меня осенило. Вся лутаемая пища автоматически складируется когда игрок возвращается на базу и игроку доступна мини-игра с обедами в столовке. Чем разнообразнее еда на складе, тем богаче меню в столовой. Тем больше здоровья восстанавливается.
Принес геймплейную идею в тред. Вдруг кому-то пригодится. Значит смотрите. Идея подойдёт к играм в жанрах песочниц и рпг. Если у вас есть различная пища в мире игры, то в какой-то момент развития персонажа она превращается в мусор, забивающий инвентарь, потому что игрок либо лечится шприцами в нф-сеттингах, либо зельями/магией в фентези и ему нет смысла есть все эти ягоды, корешки, грибочки, хлеб, мясо, сыр.
Вопрос. Как решить эту проблему?
Многие разрабы вводят систему потребностей, превращая персонажа в тамагочи. Фи.
И тут меня осенило. Вся лутаемая пища автоматически складируется когда игрок возвращается на базу и игроку доступна мини-игра с обедами в столовке. Чем разнообразнее еда на складе, тем богаче меню в столовой. Тем больше здоровья восстанавливается.
>>099658
Этому проекту почти джва года уже - начал диздок заполнять 2024.10.23, а спустя пару недель, осознал колоссальный объём работ и забросил; год назад я пробовал сделать врата >>1039341 → и забросил.
Таких проектов у меня много, думаю, уже десятки... Замечаю даже, что многие мои задумки новых игр вращаются вокруг одних и тех же нескольких тем... Раздражает, но, может, это вполне естественно?..
>>099671
Зачем делать бесполезную еду? Если хочешь еду, то изначально наделяй её "магическими" баффами. Вот, например, бутерброд с рыбой даёт буст к рыбалке на некоторое время: есть смысл взять хлеб на рыбалку, развести костёр и бустить скилл рыбалки на месте. Занимаешь игрока осмысленной работой внутри ОСНОВНОГО игрового процесса, чтобы игрок мог почувствовать, что его решения важны => фан. Т.е. необходимо создать ощущение "это Я решил взять и приготовить бутерброд, и это было полезно", а не "принудительная мини-игра опять отнимает время".
Этому проекту почти джва года уже - начал диздок заполнять 2024.10.23, а спустя пару недель, осознал колоссальный объём работ и забросил; год назад я пробовал сделать врата >>1039341 → и забросил.
Таких проектов у меня много, думаю, уже десятки... Замечаю даже, что многие мои задумки новых игр вращаются вокруг одних и тех же нескольких тем... Раздражает, но, может, это вполне естественно?..
>>099671
Зачем делать бесполезную еду? Если хочешь еду, то изначально наделяй её "магическими" баффами. Вот, например, бутерброд с рыбой даёт буст к рыбалке на некоторое время: есть смысл взять хлеб на рыбалку, развести костёр и бустить скилл рыбалки на месте. Занимаешь игрока осмысленной работой внутри ОСНОВНОГО игрового процесса, чтобы игрок мог почувствовать, что его решения важны => фан. Т.е. необходимо создать ощущение "это Я решил взять и приготовить бутерброд, и это было полезно", а не "принудительная мини-игра опять отнимает время".
357 Кб, 903x960>>099671
Дополню геймплейную идею. База должна быть доступна "из кармана" как потайное пространство, грубо говоря база-мешок, которую ты можешь в любой момент достать и нырнуть в нее, а потом вынырнуть, оказавшись в точности в той же локации, где занырнул.
Потому что все базастрои быстро доебывают необходимостью пиздохать туда-сюда.
Когда в скурим играл с таким модом. Буквально база-мешок была, и ты жил в мешке, заворачиваясь внутрь в него.
Дополню геймплейную идею. База должна быть доступна "из кармана" как потайное пространство, грубо говоря база-мешок, которую ты можешь в любой момент достать и нырнуть в нее, а потом вынырнуть, оказавшись в точности в той же локации, где занырнул.
Потому что все базастрои быстро доебывают необходимостью пиздохать туда-сюда.
Когда в скурим играл с таким модом. Буквально база-мешок была, и ты жил в мешке, заворачиваясь внутрь в него.
>>099676
Похожая механика есть в Elin: ты можешь купить себе палатку, что работает как дополнительная локация с передвижным входом, и может снижать вес лута до смешных 10% от исходного. Внутри можно растить грибочки, крафтить, спать и даже рыбачить, всё пока монстры снаружи вежливо ждут твоего выхода... Но настоящие базы всё равно фиксированные (можно телепортировать, но только за большие деньги).
Но такое далеко не всем играм подходит... Алсо, твой вариант уж слишком упрощает геймплей. Зачем тебе стараться и потеть, если ты можешь жить на базе безвылазно? Сидеть там и растить картошку, скот разводить. Удаляем 99% игры, оставляем лишь базу.
Мне интереснее, когда мобильная база физически присутствует рядом с игроком и ты её защищаешь... Повозка хотя бы какая-то, а лучше дом на колёсах. Космический корабль или что-то в этом духе. Но это, естественно, также не подходит большинству игр.
Похожая механика есть в Elin: ты можешь купить себе палатку, что работает как дополнительная локация с передвижным входом, и может снижать вес лута до смешных 10% от исходного. Внутри можно растить грибочки, крафтить, спать и даже рыбачить, всё пока монстры снаружи вежливо ждут твоего выхода... Но настоящие базы всё равно фиксированные (можно телепортировать, но только за большие деньги).
Но такое далеко не всем играм подходит... Алсо, твой вариант уж слишком упрощает геймплей. Зачем тебе стараться и потеть, если ты можешь жить на базе безвылазно? Сидеть там и растить картошку, скот разводить. Удаляем 99% игры, оставляем лишь базу.
Мне интереснее, когда мобильная база физически присутствует рядом с игроком и ты её защищаешь... Повозка хотя бы какая-то, а лучше дом на колёсах. Космический корабль или что-то в этом духе. Но это, естественно, также не подходит большинству игр.
>>099681
Согласен. Джва года жду такую игру.
Жанр обычно называют rogue-lite.
Алсо extraction shooter подходит.
>делаем локацию-базу и порталы из неё в локации-арены для кача и лута
Согласен. Джва года жду такую игру.
Жанр обычно называют rogue-lite.
Алсо extraction shooter подходит.
>>099674
Аа, ну меня тогда ещё не было.
Почему бы не попробовать урезать объем? Допустим сократить партийную рпг или что там у вас изначально в ветке до просто файтов на аренах в демке скачи и мочи вроде так было, просто кастомные битвы на аренах? Намоделить юнитов, раздать способности и мб залить куда нибудь. На условный вопрос, в чем поинт для игрока играть? Просто файтится, потому что этот игрок будет любить тактикульные битвы мне лично например нравится боевка в классических фолычах и х-ком, и участвовал там в каждой битве. Или ты о каком объеме говориш?
>Этому проекту почти джва года уже
Аа, ну меня тогда ещё не было.
>осознал колоссальный объём работ и забросил
Почему бы не попробовать урезать объем? Допустим сократить партийную рпг или что там у вас изначально в ветке до просто файтов на аренах в демке скачи и мочи вроде так было, просто кастомные битвы на аренах? Намоделить юнитов, раздать способности и мб залить куда нибудь. На условный вопрос, в чем поинт для игрока играть? Просто файтится, потому что этот игрок будет любить тактикульные битвы мне лично например нравится боевка в классических фолычах и х-ком, и участвовал там в каждой битве. Или ты о каком объеме говориш?
>>099608
Непонятно какой сложности добавляют, пару расчетов обернуть и потом как с тайлами (с номерами) работаешь. В 3Д вроде даже сетка готовая есть (но и её не долго сделать).
Три раза уже объяснил, ты троллишь? Это две разные игры.
Хотели обсудить проблему дизайна сигналов в фулл-пошаговом мире, вместо этого достал какую-то свою старую игру, не показал кода, обмазал блюром.
Мы точно хотели спагетти-код на сигналах посмотреть (вместо loop'a), или ты просто зашел показать свою старую демку?
Твои же слова
>>Непонятно что они добавляют
>Вот и я о том же - зачем гексы?..
Непонятно какой сложности добавляют, пару расчетов обернуть и потом как с тайлами (с номерами) работаешь. В 3Д вроде даже сетка готовая есть (но и её не долго сделать).
>Что не так-то, у меня же пошаговая игра?
Три раза уже объяснил, ты троллишь? Это две разные игры.
Хотели обсудить проблему дизайна сигналов в фулл-пошаговом мире, вместо этого достал какую-то свою старую игру, не показал кода, обмазал блюром.
Мы точно хотели спагетти-код на сигналах посмотреть (вместо loop'a), или ты просто зашел показать свою старую демку?
Твои же слова
>Ладно, уговорил, попробую сделать пошаговую...
Что-то охуел с того, как легко спиздить проект на годоте - буквально засунул в тулзу экзешник и получил абсолютно тот же самый проект, что и у оригинального разработчика компе, хоть сейчас меняй шильдики и заливайся в плейстор.
Есть ли в пропоузалах у мейнтейнеров что-нибудь типа il2cpp (итоговый байткод гдскрипта вместо оригинальных файлов), чтобы хотя бы получался разъебанный полурабочий проект, а не буквально оригинал?
Есть ли в пропоузалах у мейнтейнеров что-нибудь типа il2cpp (итоговый байткод гдскрипта вместо оригинальных файлов), чтобы хотя бы получался разъебанный полурабочий проект, а не буквально оригинал?
Каждые 3-4 треда одно и то же. Все хуйня, давай по-новой, и я уже бегу пиздить ваши гениальные йоба идеи на охуилиарды и/или нести в ПРОПОУЗУЛЫ кучу кода для обфускации, вместо того чтобы погуглить две минуты и найти с десяток разных готовых standalone решений. Еще потом кто-нибудь про китайцев расскажет, которые слижут твою успешную идею (а она не успешная) без декомпиляции, тупо по одному шакальному скриншоту.
196 Кб, 651x813>>099671
Просто еду не надо делать бесполезной. Тем более у еды есть узнаваемая разнообразная форма (суп от яичницы ты отличишь точно) чем такое же разнообразие у склянок. Еда должна иметь долгий единичный бафф, ты буквально выбираешь съесть на бафф урона, или реген хп (кап делать не надо, просто одна еда сменяет другую).
И вуаля, еда становится частью основного геймплея (частично так сделано в реквием сборках скайрима, там еда важная часть дроча статов)
Просто еду не надо делать бесполезной. Тем более у еды есть узнаваемая разнообразная форма (суп от яичницы ты отличишь точно) чем такое же разнообразие у склянок. Еда должна иметь долгий единичный бафф, ты буквально выбираешь съесть на бафф урона, или реген хп (кап делать не надо, просто одна еда сменяет другую).
И вуаля, еда становится частью основного геймплея (частично так сделано в реквием сборках скайрима, там еда важная часть дроча статов)
>>099695
А как иначе? Половина релизов в стиме получает меньше 10 отзывов. Из ИТТ до стима доползают единицы, но все еще неудержимо трясутся за воровство. Как хиккан, впервые за годы оказавшийся на улице, считающий что все на него смотрят и смеются.
А как иначе? Половина релизов в стиме получает меньше 10 отзывов. Из ИТТ до стима доползают единицы, но все еще неудержимо трясутся за воровство. Как хиккан, впервые за годы оказавшийся на улице, считающий что все на него смотрят и смеются.
>>099702
Нужно не заплевывать монитор, а объяснить анону, что вопрос обфускации можно отложить в самый конец проекта. Кому-то это нужно, кому-то нет, но табуировать тему - зачем?
Нужно не заплевывать монитор, а объяснить анону, что вопрос обфускации можно отложить в самый конец проекта. Кому-то это нужно, кому-то нет, но табуировать тему - зачем?
>>099710
Да, ты прав.
Да, ты прав.
>>099689
Вот попробуешь поработать с гексами - поймёшь...
Ты не ответил - зачем делать гексы? В чём причина?
Я не спорю, что игры разные, но обе - пошаговые.
Чем "фулл-пошаговость" отличается от "turn-based"?
https://en.wikipedia.org/wiki/Timekeeping_in_games
У тебя два "игрока": человек и игровой мир. Каждый анализирует ситуацию на поле некоторое время и совершает игровые действия, отмеряемые шагами. Некоторые игры могут себе позволить двигать NPC непосредственно в момент движения игрока, но на "пошаговость" эта одномоментность не влияет. Мне хотелось бы видеть ход врагов с анимациями, чтоб прослеживалось то, как они реагируют на игрока.
Ты не так понял. Задумки появились давно, но код и остальные ассеты я сделал после недавнего поста... "Проект" появляется на этапе идеи "а было бы круто", поэтому папки проекта с кодом раньше не было. Ну, разумеется, не считая той катсценки с порталом...
Там пока что очень сырой набросок, который нужно отрефакторить и причесать, прежде чем показывать. Фактически я свалил все приходящие в голову идеи в считанные 5-6 скриптов, когда по-хорошему нужно разделить обязанности на бОльшее число классов. Особенно меня позабавило то, как Player перерос из обыкновенной камеры в God Object, знающий всё и являющийся по сути почти всем. Надо разделять.
>>099688
В том-то и дело, что "юниты" - это самое сложное и трудозатратное в изначальной задумке, т.к. я хотел реализовать "как Overwatch, только offline", чтоб 3D персонажи бегали с тобой в одной команде и могли выполнять боевые задачи, но - и это главное - суть задуманного была не в геймплее как таковом, т.к. фундаментально это гача-игра, а в том, чтобы были прикольные персонажи с анимациями и т.п. А я и 1 персонажа не могу довести до презентабельного состояния... куда уж там десятки, даже сотни самых разнообразных персонажей... И реалтайм геймплей, конечно, накладывает ограничения на то, что можно реализовать в виде 3D мешей и анимаций, т.к. там критически важен отклик игры и реакции NPC...
Так что я уже "урезал объём" посредством отказа от реалтайма и заменой 3D на 2D спрайты в 3D мире. Я подумывал и о том, чтобы сделать чисто 2D игру, но подобное как-то совсем не привлекает. А тут что-то подумалось: а что, если попробовать 2.5D, чтобы 3D камерой можно было ракурс выбирать, но все герои нарочито двухмерные и анимированные с помощью деформаций, а не (только) покадрово? Это ж весьма неплохо выглядит в некоторых играх, имхо. Так я, теоретически, могу наштамповать десятки любых прикольных персонажей и даже сделать простое API, позволяющее любому добавить в игру персонажа из нескольких картинок и файла конфигурации.
В рисовании, я, увы, не силён, но мои рисунки мне нравятся... Вот и подумалось, что если я возьму простенький стиль, то нарисовать 2-3-4 спрайта на персонажа всё равно будет проще, чем сидеть над проработкой 3D моделей на уровне овервотча.
Алсо, по задумке, "количество >>> качество", то есть геймплейный цикл предполагает, что ты находишь множество неинтересных тебе персонажей, которых подбросил тебе рандом, порой даже теряешь тех, что понравились тебе (пермасмерть), и находишься в бесконечном поиске чего-то нового. Так что, кроме аватарок, нужны ещё будут рандомные параметры: "аватарка норм, а характеристики говно, печаль" или "мощный персонаж, но внешне не нравится, печаль". Контраст между этим и "ого, как удачно совпало", по задумке, должен быть наиболее впечатляющим.
Где-то в старых тредах уже описывал эту игру...
У меня были схемы геймплея, но их нужно обновить.
>Непонятно какой сложности добавляют
Вот попробуешь поработать с гексами - поймёшь...
Ты не ответил - зачем делать гексы? В чём причина?
>две разные игры
Я не спорю, что игры разные, но обе - пошаговые.
>фулл-пошаговом мире
Чем "фулл-пошаговость" отличается от "turn-based"?
https://en.wikipedia.org/wiki/Timekeeping_in_games
>In turn-based games, game flow is partitioned into defined parts, called turns, moves, or plays. Each player is allowed a period of analysis (sometimes bounded, sometimes unbounded) before committing to a game action.
У тебя два "игрока": человек и игровой мир. Каждый анализирует ситуацию на поле некоторое время и совершает игровые действия, отмеряемые шагами. Некоторые игры могут себе позволить двигать NPC непосредственно в момент движения игрока, но на "пошаговость" эта одномоментность не влияет. Мне хотелось бы видеть ход врагов с анимациями, чтоб прослеживалось то, как они реагируют на игрока.
>вместо этого достал какую-то свою старую игру
>ты просто зашел показать свою старую демку
Ты не так понял. Задумки появились давно, но код и остальные ассеты я сделал после недавнего поста... "Проект" появляется на этапе идеи "а было бы круто", поэтому папки проекта с кодом раньше не было. Ну, разумеется, не считая той катсценки с порталом...
>не показал кода
>хотели спагетти-код на сигналах посмотреть
Там пока что очень сырой набросок, который нужно отрефакторить и причесать, прежде чем показывать. Фактически я свалил все приходящие в голову идеи в считанные 5-6 скриптов, когда по-хорошему нужно разделить обязанности на бОльшее число классов. Особенно меня позабавило то, как Player перерос из обыкновенной камеры в God Object, знающий всё и являющийся по сути почти всем. Надо разделять.
>>099688
>урезать объем
>Намоделить юнитов
В том-то и дело, что "юниты" - это самое сложное и трудозатратное в изначальной задумке, т.к. я хотел реализовать "как Overwatch, только offline", чтоб 3D персонажи бегали с тобой в одной команде и могли выполнять боевые задачи, но - и это главное - суть задуманного была не в геймплее как таковом, т.к. фундаментально это гача-игра, а в том, чтобы были прикольные персонажи с анимациями и т.п. А я и 1 персонажа не могу довести до презентабельного состояния... куда уж там десятки, даже сотни самых разнообразных персонажей... И реалтайм геймплей, конечно, накладывает ограничения на то, что можно реализовать в виде 3D мешей и анимаций, т.к. там критически важен отклик игры и реакции NPC...
Так что я уже "урезал объём" посредством отказа от реалтайма и заменой 3D на 2D спрайты в 3D мире. Я подумывал и о том, чтобы сделать чисто 2D игру, но подобное как-то совсем не привлекает. А тут что-то подумалось: а что, если попробовать 2.5D, чтобы 3D камерой можно было ракурс выбирать, но все герои нарочито двухмерные и анимированные с помощью деформаций, а не (только) покадрово? Это ж весьма неплохо выглядит в некоторых играх, имхо. Так я, теоретически, могу наштамповать десятки любых прикольных персонажей и даже сделать простое API, позволяющее любому добавить в игру персонажа из нескольких картинок и файла конфигурации.
В рисовании, я, увы, не силён, но мои рисунки мне нравятся... Вот и подумалось, что если я возьму простенький стиль, то нарисовать 2-3-4 спрайта на персонажа всё равно будет проще, чем сидеть над проработкой 3D моделей на уровне овервотча.
Алсо, по задумке, "количество >>> качество", то есть геймплейный цикл предполагает, что ты находишь множество неинтересных тебе персонажей, которых подбросил тебе рандом, порой даже теряешь тех, что понравились тебе (пермасмерть), и находишься в бесконечном поиске чего-то нового. Так что, кроме аватарок, нужны ещё будут рандомные параметры: "аватарка норм, а характеристики говно, печаль" или "мощный персонаж, но внешне не нравится, печаль". Контраст между этим и "ого, как удачно совпало", по задумке, должен быть наиболее впечатляющим.
Где-то в старых тредах уже описывал эту игру...
У меня были схемы геймплея, но их нужно обновить.
>>099689
Вот попробуешь поработать с гексами - поймёшь...
Ты не ответил - зачем делать гексы? В чём причина?
Я не спорю, что игры разные, но обе - пошаговые.
Чем "фулл-пошаговость" отличается от "turn-based"?
https://en.wikipedia.org/wiki/Timekeeping_in_games
У тебя два "игрока": человек и игровой мир. Каждый анализирует ситуацию на поле некоторое время и совершает игровые действия, отмеряемые шагами. Некоторые игры могут себе позволить двигать NPC непосредственно в момент движения игрока, но на "пошаговость" эта одномоментность не влияет. Мне хотелось бы видеть ход врагов с анимациями, чтоб прослеживалось то, как они реагируют на игрока.
Ты не так понял. Задумки появились давно, но код и остальные ассеты я сделал после недавнего поста... "Проект" появляется на этапе идеи "а было бы круто", поэтому папки проекта с кодом раньше не было. Ну, разумеется, не считая той катсценки с порталом...
Там пока что очень сырой набросок, который нужно отрефакторить и причесать, прежде чем показывать. Фактически я свалил все приходящие в голову идеи в считанные 5-6 скриптов, когда по-хорошему нужно разделить обязанности на бОльшее число классов. Особенно меня позабавило то, как Player перерос из обыкновенной камеры в God Object, знающий всё и являющийся по сути почти всем. Надо разделять.
>>099688
В том-то и дело, что "юниты" - это самое сложное и трудозатратное в изначальной задумке, т.к. я хотел реализовать "как Overwatch, только offline", чтоб 3D персонажи бегали с тобой в одной команде и могли выполнять боевые задачи, но - и это главное - суть задуманного была не в геймплее как таковом, т.к. фундаментально это гача-игра, а в том, чтобы были прикольные персонажи с анимациями и т.п. А я и 1 персонажа не могу довести до презентабельного состояния... куда уж там десятки, даже сотни самых разнообразных персонажей... И реалтайм геймплей, конечно, накладывает ограничения на то, что можно реализовать в виде 3D мешей и анимаций, т.к. там критически важен отклик игры и реакции NPC...
Так что я уже "урезал объём" посредством отказа от реалтайма и заменой 3D на 2D спрайты в 3D мире. Я подумывал и о том, чтобы сделать чисто 2D игру, но подобное как-то совсем не привлекает. А тут что-то подумалось: а что, если попробовать 2.5D, чтобы 3D камерой можно было ракурс выбирать, но все герои нарочито двухмерные и анимированные с помощью деформаций, а не (только) покадрово? Это ж весьма неплохо выглядит в некоторых играх, имхо. Так я, теоретически, могу наштамповать десятки любых прикольных персонажей и даже сделать простое API, позволяющее любому добавить в игру персонажа из нескольких картинок и файла конфигурации.
В рисовании, я, увы, не силён, но мои рисунки мне нравятся... Вот и подумалось, что если я возьму простенький стиль, то нарисовать 2-3-4 спрайта на персонажа всё равно будет проще, чем сидеть над проработкой 3D моделей на уровне овервотча.
Алсо, по задумке, "количество >>> качество", то есть геймплейный цикл предполагает, что ты находишь множество неинтересных тебе персонажей, которых подбросил тебе рандом, порой даже теряешь тех, что понравились тебе (пермасмерть), и находишься в бесконечном поиске чего-то нового. Так что, кроме аватарок, нужны ещё будут рандомные параметры: "аватарка норм, а характеристики говно, печаль" или "мощный персонаж, но внешне не нравится, печаль". Контраст между этим и "ого, как удачно совпало", по задумке, должен быть наиболее впечатляющим.
Где-то в старых тредах уже описывал эту игру...
У меня были схемы геймплея, но их нужно обновить.
>Непонятно какой сложности добавляют
Вот попробуешь поработать с гексами - поймёшь...
Ты не ответил - зачем делать гексы? В чём причина?
>две разные игры
Я не спорю, что игры разные, но обе - пошаговые.
>фулл-пошаговом мире
Чем "фулл-пошаговость" отличается от "turn-based"?
https://en.wikipedia.org/wiki/Timekeeping_in_games
>In turn-based games, game flow is partitioned into defined parts, called turns, moves, or plays. Each player is allowed a period of analysis (sometimes bounded, sometimes unbounded) before committing to a game action.
У тебя два "игрока": человек и игровой мир. Каждый анализирует ситуацию на поле некоторое время и совершает игровые действия, отмеряемые шагами. Некоторые игры могут себе позволить двигать NPC непосредственно в момент движения игрока, но на "пошаговость" эта одномоментность не влияет. Мне хотелось бы видеть ход врагов с анимациями, чтоб прослеживалось то, как они реагируют на игрока.
>вместо этого достал какую-то свою старую игру
>ты просто зашел показать свою старую демку
Ты не так понял. Задумки появились давно, но код и остальные ассеты я сделал после недавнего поста... "Проект" появляется на этапе идеи "а было бы круто", поэтому папки проекта с кодом раньше не было. Ну, разумеется, не считая той катсценки с порталом...
>не показал кода
>хотели спагетти-код на сигналах посмотреть
Там пока что очень сырой набросок, который нужно отрефакторить и причесать, прежде чем показывать. Фактически я свалил все приходящие в голову идеи в считанные 5-6 скриптов, когда по-хорошему нужно разделить обязанности на бОльшее число классов. Особенно меня позабавило то, как Player перерос из обыкновенной камеры в God Object, знающий всё и являющийся по сути почти всем. Надо разделять.
>>099688
>урезать объем
>Намоделить юнитов
В том-то и дело, что "юниты" - это самое сложное и трудозатратное в изначальной задумке, т.к. я хотел реализовать "как Overwatch, только offline", чтоб 3D персонажи бегали с тобой в одной команде и могли выполнять боевые задачи, но - и это главное - суть задуманного была не в геймплее как таковом, т.к. фундаментально это гача-игра, а в том, чтобы были прикольные персонажи с анимациями и т.п. А я и 1 персонажа не могу довести до презентабельного состояния... куда уж там десятки, даже сотни самых разнообразных персонажей... И реалтайм геймплей, конечно, накладывает ограничения на то, что можно реализовать в виде 3D мешей и анимаций, т.к. там критически важен отклик игры и реакции NPC...
Так что я уже "урезал объём" посредством отказа от реалтайма и заменой 3D на 2D спрайты в 3D мире. Я подумывал и о том, чтобы сделать чисто 2D игру, но подобное как-то совсем не привлекает. А тут что-то подумалось: а что, если попробовать 2.5D, чтобы 3D камерой можно было ракурс выбирать, но все герои нарочито двухмерные и анимированные с помощью деформаций, а не (только) покадрово? Это ж весьма неплохо выглядит в некоторых играх, имхо. Так я, теоретически, могу наштамповать десятки любых прикольных персонажей и даже сделать простое API, позволяющее любому добавить в игру персонажа из нескольких картинок и файла конфигурации.
В рисовании, я, увы, не силён, но мои рисунки мне нравятся... Вот и подумалось, что если я возьму простенький стиль, то нарисовать 2-3-4 спрайта на персонажа всё равно будет проще, чем сидеть над проработкой 3D моделей на уровне овервотча.
Алсо, по задумке, "количество >>> качество", то есть геймплейный цикл предполагает, что ты находишь множество неинтересных тебе персонажей, которых подбросил тебе рандом, порой даже теряешь тех, что понравились тебе (пермасмерть), и находишься в бесконечном поиске чего-то нового. Так что, кроме аватарок, нужны ещё будут рандомные параметры: "аватарка норм, а характеристики говно, печаль" или "мощный персонаж, но внешне не нравится, печаль". Контраст между этим и "ого, как удачно совпало", по задумке, должен быть наиболее впечатляющим.
Где-то в старых тредах уже описывал эту игру...
У меня были схемы геймплея, но их нужно обновить.
>>099745
Полгода назад тестил говнину. Больше боялся этих гексов чем реальных проблем.
Помимо того что ты и сам знаешь - хорошо подходит к плавным высотам для 3D.
Тем что нужно ждать конца анимации всех кто ходит в локации (даже игрока). Я уже говорил ни раз.
У этого чела есть подробный туториал, правда на юнити, но думаю тебе достаточно скила чтобы адаптировать в годот
https://catlikecoding.com/
Увы по годоту таких масштабных туториалов нет, но чтобы не травмировать движкосрачника, кину тутор по true-top-down-2d, выглядит прикольно.
https://catlikecoding.com/godot/true-top-down-2d/
>Вот попробуешь поработать с гексами - поймёшь...
Полгода назад тестил говнину. Больше боялся этих гексов чем реальных проблем.
>Ты не ответил - зачем делать гексы? В чём причина?
Помимо того что ты и сам знаешь - хорошо подходит к плавным высотам для 3D.
>Чем "фулл-пошаговость" отличается
Тем что нужно ждать конца анимации всех кто ходит в локации (даже игрока). Я уже говорил ни раз.
>Пик1
У этого чела есть подробный туториал, правда на юнити, но думаю тебе достаточно скила чтобы адаптировать в годот
https://catlikecoding.com/
>Пик2,3
Увы по годоту таких масштабных туториалов нет, но чтобы не травмировать движкосрачника, кину тутор по true-top-down-2d, выглядит прикольно.
https://catlikecoding.com/godot/true-top-down-2d/
>>099745
сразу рагнарек вспоминается
а сами спрайты персонажа не будут генерироваться? Мне кажется это самое тяжелое было бы, даже 4 кадра 2 направления, атака и дамаг, но при этом без генерации, как-то неполноценно чтоли будет. По крайне мере я привязываюсь больше именно к фигуркам, а не аватаркам
А так задумка интересная, но тут да, нужно сесть и рисовать.
>попробовать 2.5D, чтобы 3D камерой можно было ракурс выбирать
>Это ж весьма неплохо выглядит в некоторых играх
сразу рагнарек вспоминается
>аватарка норм, а характеристики говно, печаль" или "мощный персонаж, но внешне не нравится, печаль
а сами спрайты персонажа не будут генерироваться? Мне кажется это самое тяжелое было бы, даже 4 кадра 2 направления, атака и дамаг, но при этом без генерации, как-то неполноценно чтоли будет. По крайне мере я привязываюсь больше именно к фигуркам, а не аватаркам
А так задумка интересная, но тут да, нужно сесть и рисовать.
кайнд оф оффтопик
Все просто ебанулись на симуляторах ларьков, остановитесь
Ещё я охуел от того, сколько РТС сейчас выходит, обновляется или в разработке, но это богоудоное дело, продолжайте
Все просто ебанулись на симуляторах ларьков, остановитесь
Ещё я охуел от того, сколько РТС сейчас выходит, обновляется или в разработке, но это богоудоное дело, продолжайте
>>099800
Их легко нанейрослопить, и вот.
Их легко нанейрослопить, и вот.
>>099800
Незаслуженно забытый жанр, до сих пор не пойму почему произошел упадок интереса (пришлось десятилетиями долбиться в монопольные подделки пароходов)
>сколько РТС сейчас выходит
Незаслуженно забытый жанр, до сих пор не пойму почему произошел упадок интереса (пришлось десятилетиями долбиться в монопольные подделки пароходов)
>>099919
РТС был убит онлайном, где казуалы оказались раскаты в лепеху окрщиками с надроченым микроконтролем. А в соло уже неинтересно.
РТС был убит онлайном, где казуалы оказались раскаты в лепеху окрщиками с надроченым микроконтролем. А в соло уже неинтересно.
>>099924
Возможно это тоже повлияло, но как-будто было что-то еще.
Знаешь, дети девяностых и нулевых имели более яркое абстрактное мышление (яркую фантазию) и в условиях слабых компов приходилось додумывать погружение. Это для тех лет ты генерал управляющий своей армией, своей маленькой колонией, имерией, а для нового поколение с более ярким контентом и даже видео контентом - игра превращается в однообразный кликер.
Как я пришел к такой мысле.
Я расспрашивал в дискорде про HOI4 у подрастающего поколения (где тимой мы играли в другую игру), для кого-то есть то погружение управления странной в историческую эпоху, ощущение командование армий и дивизиями, а кому-то игра видеться просто как однообразный кликер (чем технически она и есть).
Думаю из-за этого РТС и сгинула. В эпоху изобилия контента, нужно более значительное усилие чтобы передать абстрактное погружение, иначе игра будет просто кликером
Возможно это тоже повлияло, но как-будто было что-то еще.
Знаешь, дети девяностых и нулевых имели более яркое абстрактное мышление (яркую фантазию) и в условиях слабых компов приходилось додумывать погружение. Это для тех лет ты генерал управляющий своей армией, своей маленькой колонией, имерией, а для нового поколение с более ярким контентом и даже видео контентом - игра превращается в однообразный кликер.
Как я пришел к такой мысле.
Я расспрашивал в дискорде про HOI4 у подрастающего поколения (где тимой мы играли в другую игру), для кого-то есть то погружение управления странной в историческую эпоху, ощущение командование армий и дивизиями, а кому-то игра видеться просто как однообразный кликер (чем технически она и есть).
Думаю из-за этого РТС и сгинула. В эпоху изобилия контента, нужно более значительное усилие чтобы передать абстрактное погружение, иначе игра будет просто кликером
А помните ещё, анонсировали https://store.steampowered.com/app/2956040/PVKK_Planetenverteidigungskanonenkommandant/ на Godot уже года 2 как и до сих пор не выпустили. В общем их обогнали и выпустили клон https://store.steampowered.com/app/2950790/IRON_NEST_Heavy_Turret_Simulator/, так что делайте игры
>>099963
На пик 2 как будто проёбаны пропорции. При таком калибре под башней ещё механизм заряжания на несколько метров вниз уходит. Ну и ноги врятли такое выдержат. Короче я бы такое не купил.
На пик 2 как будто проёбаны пропорции. При таком калибре под башней ещё механизм заряжания на несколько метров вниз уходит. Ну и ноги врятли такое выдержат. Короче я бы такое не купил.
28 Кб, 469x128>>099963
Удар в спину, господа.
Удар в спину, господа.
6,2 Мб, mp4,1280x720, 2:06
>>099390
Я попробовал сыграть... Одним словом - Д У Х О Т А, как это сегодня модно говорить: душный интерфейс, душные описания душных механик, душная графика, душная музыка, душный мир про душных людей и душных зомби. Игра с порога наваливает на игрока 100500 ненужных механик, вынуждающих игрока сидеть и разбираться в сотне разных ненужных параметров, и применять кучу предметов для того, что в любой игре здорового человека в принципе отсутствует (вроде переломов костей и "болевых ощущений" персонажа). При этом вся боёвка сводится к тому, что слабого врага ты закликиваешь насмерть, а от сильного убегаешь (а-ля Stardew Valley, только тут тебе могут ногу сломать и ты уже не убежишь никуда, лол). Ради чего в это уныние играть? Ради усиления депрессии в реальной жизни? У меня и в реальности достаточно боли и страданий от бессилия... Такого рода игры специально создаются, чтоб нельзя было почувствовать подвох и рефанднуть за 2 часа, а потом игрок испытывает чувство потраченного впустую времени и начинает оправдывать игру, мол, "наверное, это я ничего не понял, а игра-то хорошая - не зря время на неё потратил". Но я уже опытный, меня такими грязными трюками не проведёшь, я слишком много игр перепробовал.
>>099753
А нужны ли эти "плавные высоты", если они будут настолько неприятно выглядеть? Повторюсь, я успешно реализовал генерацию из шестигранных призм около пяти лет назад, и мне не понравилось. Шестигранные призмы добавляют массу головной боли как с точки зрения математики (в туториалах не рассказывают), так и с точки зрения графики - делать красиво на основе шестигранных призм практически невозможно. "Плавные высоты" можно сделать и на обычной карте высот, как это делается в большинстве нормальных игр, а если нужны именно кубики - то существует техника "марширующих кубов", сглаживающая углы намного лучше, чем призмы. Вопрос только в том, нужны ли конкретной игре такие бесформенные обмылки?
>>099763
"Аватар" - это и есть спрайты, которые бегают по карте... По лору, который я придумывал два года назад, сеттинг игры - постапокалипсис в масштабах мультивселенной. Из-за вышедших из-под контроля экспериментов множество ранее параллельных вселенных столкнулись, а их пространство-время перепуталось и стало в основном нестабильным. Но иногда в мире всё ещё встречаются временные или постоянные участки стабильного пространства. Игрок находится на космической станции, выжив только за счёт того, что станция была в постоянно стабильном пространстве. У станции есть портал, который можно настроить на другие участки, где иногда возникают другие порталы. Геймплей представляет собой отправку героев на исследование временно стабильного участка с добычей лута и спасением новых персонажей (нужно успеть вернуть всех своих персонажей и/или их трупы в портал, пока зона не разрушилась; оживить можно лишь тех, кто успел добраться до станции хотя бы в мёртвом виде). При этом, так как один и тот же персонаж существовал во множестве параллельных вселенных, в новой, слитой в неразбериху реальности можно встретить этого персонажа много раз подряд - и они все будут независимыми личностями со своими особенностями, но внешне они как близнецы. То есть, их спрайты похожи друг на друга, потому что по лору они одни и те же существа, но из разных вселенных. Ну, конечно, можно накинуть какие-то элементы вроде волос и одежды в виде масок, позволяющих менять оттенок из кода (CanvasItem.modulate или self_modulate), типа как в Skull Girls...
>глянешь игру
>Стоншард же показал, что
>этот вариант даже меня не угнетает
Я попробовал сыграть... Одним словом - Д У Х О Т А, как это сегодня модно говорить: душный интерфейс, душные описания душных механик, душная графика, душная музыка, душный мир про душных людей и душных зомби. Игра с порога наваливает на игрока 100500 ненужных механик, вынуждающих игрока сидеть и разбираться в сотне разных ненужных параметров, и применять кучу предметов для того, что в любой игре здорового человека в принципе отсутствует (вроде переломов костей и "болевых ощущений" персонажа). При этом вся боёвка сводится к тому, что слабого врага ты закликиваешь насмерть, а от сильного убегаешь (а-ля Stardew Valley, только тут тебе могут ногу сломать и ты уже не убежишь никуда, лол). Ради чего в это уныние играть? Ради усиления депрессии в реальной жизни? У меня и в реальности достаточно боли и страданий от бессилия... Такого рода игры специально создаются, чтоб нельзя было почувствовать подвох и рефанднуть за 2 часа, а потом игрок испытывает чувство потраченного впустую времени и начинает оправдывать игру, мол, "наверное, это я ничего не понял, а игра-то хорошая - не зря время на неё потратил". Но я уже опытный, меня такими грязными трюками не проведёшь, я слишком много игр перепробовал.
>>099753
>плавным высотам для 3D
А нужны ли эти "плавные высоты", если они будут настолько неприятно выглядеть? Повторюсь, я успешно реализовал генерацию из шестигранных призм около пяти лет назад, и мне не понравилось. Шестигранные призмы добавляют массу головной боли как с точки зрения математики (в туториалах не рассказывают), так и с точки зрения графики - делать красиво на основе шестигранных призм практически невозможно. "Плавные высоты" можно сделать и на обычной карте высот, как это делается в большинстве нормальных игр, а если нужны именно кубики - то существует техника "марширующих кубов", сглаживающая углы намного лучше, чем призмы. Вопрос только в том, нужны ли конкретной игре такие бесформенные обмылки?
>>099763
>а сами спрайты персонажа не будут генерироваться?
>при этом без генерации, как-то неполноценно чтоли будет
"Аватар" - это и есть спрайты, которые бегают по карте... По лору, который я придумывал два года назад, сеттинг игры - постапокалипсис в масштабах мультивселенной. Из-за вышедших из-под контроля экспериментов множество ранее параллельных вселенных столкнулись, а их пространство-время перепуталось и стало в основном нестабильным. Но иногда в мире всё ещё встречаются временные или постоянные участки стабильного пространства. Игрок находится на космической станции, выжив только за счёт того, что станция была в постоянно стабильном пространстве. У станции есть портал, который можно настроить на другие участки, где иногда возникают другие порталы. Геймплей представляет собой отправку героев на исследование временно стабильного участка с добычей лута и спасением новых персонажей (нужно успеть вернуть всех своих персонажей и/или их трупы в портал, пока зона не разрушилась; оживить можно лишь тех, кто успел добраться до станции хотя бы в мёртвом виде). При этом, так как один и тот же персонаж существовал во множестве параллельных вселенных, в новой, слитой в неразбериху реальности можно встретить этого персонажа много раз подряд - и они все будут независимыми личностями со своими особенностями, но внешне они как близнецы. То есть, их спрайты похожи друг на друга, потому что по лору они одни и те же существа, но из разных вселенных. Ну, конечно, можно накинуть какие-то элементы вроде волос и одежды в виде масок, позволяющих менять оттенок из кода (CanvasItem.modulate или self_modulate), типа как в Skull Girls...
6,2 Мб, mp4,1280x720, 2:06
>>099390
Я попробовал сыграть... Одним словом - Д У Х О Т А, как это сегодня модно говорить: душный интерфейс, душные описания душных механик, душная графика, душная музыка, душный мир про душных людей и душных зомби. Игра с порога наваливает на игрока 100500 ненужных механик, вынуждающих игрока сидеть и разбираться в сотне разных ненужных параметров, и применять кучу предметов для того, что в любой игре здорового человека в принципе отсутствует (вроде переломов костей и "болевых ощущений" персонажа). При этом вся боёвка сводится к тому, что слабого врага ты закликиваешь насмерть, а от сильного убегаешь (а-ля Stardew Valley, только тут тебе могут ногу сломать и ты уже не убежишь никуда, лол). Ради чего в это уныние играть? Ради усиления депрессии в реальной жизни? У меня и в реальности достаточно боли и страданий от бессилия... Такого рода игры специально создаются, чтоб нельзя было почувствовать подвох и рефанднуть за 2 часа, а потом игрок испытывает чувство потраченного впустую времени и начинает оправдывать игру, мол, "наверное, это я ничего не понял, а игра-то хорошая - не зря время на неё потратил". Но я уже опытный, меня такими грязными трюками не проведёшь, я слишком много игр перепробовал.
>>099753
А нужны ли эти "плавные высоты", если они будут настолько неприятно выглядеть? Повторюсь, я успешно реализовал генерацию из шестигранных призм около пяти лет назад, и мне не понравилось. Шестигранные призмы добавляют массу головной боли как с точки зрения математики (в туториалах не рассказывают), так и с точки зрения графики - делать красиво на основе шестигранных призм практически невозможно. "Плавные высоты" можно сделать и на обычной карте высот, как это делается в большинстве нормальных игр, а если нужны именно кубики - то существует техника "марширующих кубов", сглаживающая углы намного лучше, чем призмы. Вопрос только в том, нужны ли конкретной игре такие бесформенные обмылки?
>>099763
"Аватар" - это и есть спрайты, которые бегают по карте... По лору, который я придумывал два года назад, сеттинг игры - постапокалипсис в масштабах мультивселенной. Из-за вышедших из-под контроля экспериментов множество ранее параллельных вселенных столкнулись, а их пространство-время перепуталось и стало в основном нестабильным. Но иногда в мире всё ещё встречаются временные или постоянные участки стабильного пространства. Игрок находится на космической станции, выжив только за счёт того, что станция была в постоянно стабильном пространстве. У станции есть портал, который можно настроить на другие участки, где иногда возникают другие порталы. Геймплей представляет собой отправку героев на исследование временно стабильного участка с добычей лута и спасением новых персонажей (нужно успеть вернуть всех своих персонажей и/или их трупы в портал, пока зона не разрушилась; оживить можно лишь тех, кто успел добраться до станции хотя бы в мёртвом виде). При этом, так как один и тот же персонаж существовал во множестве параллельных вселенных, в новой, слитой в неразбериху реальности можно встретить этого персонажа много раз подряд - и они все будут независимыми личностями со своими особенностями, но внешне они как близнецы. То есть, их спрайты похожи друг на друга, потому что по лору они одни и те же существа, но из разных вселенных. Ну, конечно, можно накинуть какие-то элементы вроде волос и одежды в виде масок, позволяющих менять оттенок из кода (CanvasItem.modulate или self_modulate), типа как в Skull Girls...
>глянешь игру
>Стоншард же показал, что
>этот вариант даже меня не угнетает
Я попробовал сыграть... Одним словом - Д У Х О Т А, как это сегодня модно говорить: душный интерфейс, душные описания душных механик, душная графика, душная музыка, душный мир про душных людей и душных зомби. Игра с порога наваливает на игрока 100500 ненужных механик, вынуждающих игрока сидеть и разбираться в сотне разных ненужных параметров, и применять кучу предметов для того, что в любой игре здорового человека в принципе отсутствует (вроде переломов костей и "болевых ощущений" персонажа). При этом вся боёвка сводится к тому, что слабого врага ты закликиваешь насмерть, а от сильного убегаешь (а-ля Stardew Valley, только тут тебе могут ногу сломать и ты уже не убежишь никуда, лол). Ради чего в это уныние играть? Ради усиления депрессии в реальной жизни? У меня и в реальности достаточно боли и страданий от бессилия... Такого рода игры специально создаются, чтоб нельзя было почувствовать подвох и рефанднуть за 2 часа, а потом игрок испытывает чувство потраченного впустую времени и начинает оправдывать игру, мол, "наверное, это я ничего не понял, а игра-то хорошая - не зря время на неё потратил". Но я уже опытный, меня такими грязными трюками не проведёшь, я слишком много игр перепробовал.
>>099753
>плавным высотам для 3D
А нужны ли эти "плавные высоты", если они будут настолько неприятно выглядеть? Повторюсь, я успешно реализовал генерацию из шестигранных призм около пяти лет назад, и мне не понравилось. Шестигранные призмы добавляют массу головной боли как с точки зрения математики (в туториалах не рассказывают), так и с точки зрения графики - делать красиво на основе шестигранных призм практически невозможно. "Плавные высоты" можно сделать и на обычной карте высот, как это делается в большинстве нормальных игр, а если нужны именно кубики - то существует техника "марширующих кубов", сглаживающая углы намного лучше, чем призмы. Вопрос только в том, нужны ли конкретной игре такие бесформенные обмылки?
>>099763
>а сами спрайты персонажа не будут генерироваться?
>при этом без генерации, как-то неполноценно чтоли будет
"Аватар" - это и есть спрайты, которые бегают по карте... По лору, который я придумывал два года назад, сеттинг игры - постапокалипсис в масштабах мультивселенной. Из-за вышедших из-под контроля экспериментов множество ранее параллельных вселенных столкнулись, а их пространство-время перепуталось и стало в основном нестабильным. Но иногда в мире всё ещё встречаются временные или постоянные участки стабильного пространства. Игрок находится на космической станции, выжив только за счёт того, что станция была в постоянно стабильном пространстве. У станции есть портал, который можно настроить на другие участки, где иногда возникают другие порталы. Геймплей представляет собой отправку героев на исследование временно стабильного участка с добычей лута и спасением новых персонажей (нужно успеть вернуть всех своих персонажей и/или их трупы в портал, пока зона не разрушилась; оживить можно лишь тех, кто успел добраться до станции хотя бы в мёртвом виде). При этом, так как один и тот же персонаж существовал во множестве параллельных вселенных, в новой, слитой в неразбериху реальности можно встретить этого персонажа много раз подряд - и они все будут независимыми личностями со своими особенностями, но внешне они как близнецы. То есть, их спрайты похожи друг на друга, потому что по лору они одни и те же существа, но из разных вселенных. Ну, конечно, можно накинуть какие-то элементы вроде волос и одежды в виде масок, позволяющих менять оттенок из кода (CanvasItem.modulate или self_modulate), типа как в Skull Girls...
>>100032
Ну ты задушнил. Я про механику фулл-пошагового мира.
А так да, там многое в игре сделано чтобы искусственно затянуть геймплей, игра просто завуалированная доилка. Но в тоже время может передать погружение.
Почему редотики ничего не делают? они и в жизни ничего не делают, но я про демку твою
>Одним словом - Д У Х О Т А,
Ну ты задушнил. Я про механику фулл-пошагового мира.
А так да, там многое в игре сделано чтобы искусственно затянуть геймплей, игра просто завуалированная доилка. Но в тоже время может передать погружение.
>видео
Почему редотики ничего не делают? они и в жизни ничего не делают, но я про демку твою
А если игра по типу слей зе спайр 2 с коопом, то легко ли переделывать игру под кооп? нет просто функции типа "пусть тут у него на экране будет показываться как и у меня, а вот тут только по отдельности"? нужно будет прям всё переписывать?
>>100084
Что-то такое имеется в движке, но я не разбирался в деталях, почитай сам:
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Для постоянной синхронизации состояния нод, как я понял, есть вот эти ноды:
https://docs.godotengine.org/en/stable/classes/class_multiplayersynchronizer.html
https://docs.godotengine.org/en/stable/classes/class_multiplayerspawner.html
Если каждый игрок ждёт своего "хода" - должно быть относительно легко...
Самые большие трудности с мультиплеером у экшен-игр - игр "на реакцию".
>>100090
Во-первых, нужно скукожить вьюпорт, не затрагивая рендеринг GUI:
https://docs.godotengine.org/en/stable/tutorials/3d/resolution_scaling.html
Открываешь "Project Settings > Rendering > Scaling 3D", там выбираешь:
Во-вторых, для кубиков и декораций на 3D сетке можно юзать GridMap:
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
В-третьих, для "2.5D спрайтов" можно использовать ноду Sprite3D:
https://docs.godotengine.org/en/stable/classes/class_sprite3d.html
Настройки для начала можешь выбрать такие:
Также очень рекомендую заранее ознакомиться с SubViewport:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/shaders/using_viewport_as_texture.html
Например, можно рендерить стопку из картинок в единственный Sprite3D:
Освещение и лампочки, скорее всего, самые обычные для 3D.
Текстуры в той игре сгенерированы нейронкой и/или сжаты.
Звучит сложно, но всё это делается в Godot за минуты...
>>100044
У тебя джва места для сидения:
1. В кресле приятно сидеть - утопаешь в его мягкости, аж в сон клонит.
2. На колышке неудобно сидеть - жопа болит, елозишь, ругаешься.
На каком "погрузишься", а на каком - "можешь погрузиться"?
Вопрос с подвохом. Думай.
Потому что отвлекаюсь и трачу время на посты типа этого, а не на свои игры...
>пусть тут у него на экране будет показываться как и у меня
Что-то такое имеется в движке, но я не разбирался в деталях, почитай сам:
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Для постоянной синхронизации состояния нод, как я понял, есть вот эти ноды:
https://docs.godotengine.org/en/stable/classes/class_multiplayersynchronizer.html
https://docs.godotengine.org/en/stable/classes/class_multiplayerspawner.html
>слей зе спайр 2 с коопом, то легко ли переделывать
Если каждый игрок ждёт своего "хода" - должно быть относительно легко...
Самые большие трудности с мультиплеером у экшен-игр - игр "на реакцию".
>>100090
Во-первых, нужно скукожить вьюпорт, не затрагивая рендеринг GUI:
https://docs.godotengine.org/en/stable/tutorials/3d/resolution_scaling.html
Открываешь "Project Settings > Rendering > Scaling 3D", там выбираешь:
>Mode = Nearest # чтоб "пиксели" не размазывало по экрану
>Scale = по вкусу: 0.5 (2x2), 0.3333 (3x3), 0.25 (4x4), 0.2 (5x5)...
Во-вторых, для кубиков и декораций на 3D сетке можно юзать GridMap:
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
В-третьих, для "2.5D спрайтов" можно использовать ноду Sprite3D:
https://docs.godotengine.org/en/stable/classes/class_sprite3d.html
Настройки для начала можешь выбрать такие:
>billboard = billboard_fixed_y (чтоб смотрели в камеру)
>texture_filter = nearest (чтоб крупные пиксели были)
Также очень рекомендую заранее ознакомиться с SubViewport:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/shaders/using_viewport_as_texture.html
Например, можно рендерить стопку из картинок в единственный Sprite3D:
>Sprite3D # что видим на экране, использует ViewportTexture
>_ SubViewport
>_ _ Sprite2D # голова
>_ _ Sprite2D # тело
>_ _ Sprite2D # оружие и т.п.
>_ _ AnimationPlayer и т.д.
Освещение и лампочки, скорее всего, самые обычные для 3D.
Текстуры в той игре сгенерированы нейронкой и/или сжаты.
Звучит сложно, но всё это делается в Godot за минуты...
>>100044
>Но в тоже время может передать погружение.
У тебя джва места для сидения:
1. В кресле приятно сидеть - утопаешь в его мягкости, аж в сон клонит.
2. На колышке неудобно сидеть - жопа болит, елозишь, ругаешься.
На каком "погрузишься", а на каком - "можешь погрузиться"?
Вопрос с подвохом. Думай.
>Почему редотики ничего не делают?
Потому что отвлекаюсь и трачу время на посты типа этого, а не на свои игры...
>>100084
Что-то такое имеется в движке, но я не разбирался в деталях, почитай сам:
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Для постоянной синхронизации состояния нод, как я понял, есть вот эти ноды:
https://docs.godotengine.org/en/stable/classes/class_multiplayersynchronizer.html
https://docs.godotengine.org/en/stable/classes/class_multiplayerspawner.html
Если каждый игрок ждёт своего "хода" - должно быть относительно легко...
Самые большие трудности с мультиплеером у экшен-игр - игр "на реакцию".
>>100090
Во-первых, нужно скукожить вьюпорт, не затрагивая рендеринг GUI:
https://docs.godotengine.org/en/stable/tutorials/3d/resolution_scaling.html
Открываешь "Project Settings > Rendering > Scaling 3D", там выбираешь:
Во-вторых, для кубиков и декораций на 3D сетке можно юзать GridMap:
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
В-третьих, для "2.5D спрайтов" можно использовать ноду Sprite3D:
https://docs.godotengine.org/en/stable/classes/class_sprite3d.html
Настройки для начала можешь выбрать такие:
Также очень рекомендую заранее ознакомиться с SubViewport:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/shaders/using_viewport_as_texture.html
Например, можно рендерить стопку из картинок в единственный Sprite3D:
Освещение и лампочки, скорее всего, самые обычные для 3D.
Текстуры в той игре сгенерированы нейронкой и/или сжаты.
Звучит сложно, но всё это делается в Godot за минуты...
>>100044
У тебя джва места для сидения:
1. В кресле приятно сидеть - утопаешь в его мягкости, аж в сон клонит.
2. На колышке неудобно сидеть - жопа болит, елозишь, ругаешься.
На каком "погрузишься", а на каком - "можешь погрузиться"?
Вопрос с подвохом. Думай.
Потому что отвлекаюсь и трачу время на посты типа этого, а не на свои игры...
>пусть тут у него на экране будет показываться как и у меня
Что-то такое имеется в движке, но я не разбирался в деталях, почитай сам:
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Для постоянной синхронизации состояния нод, как я понял, есть вот эти ноды:
https://docs.godotengine.org/en/stable/classes/class_multiplayersynchronizer.html
https://docs.godotengine.org/en/stable/classes/class_multiplayerspawner.html
>слей зе спайр 2 с коопом, то легко ли переделывать
Если каждый игрок ждёт своего "хода" - должно быть относительно легко...
Самые большие трудности с мультиплеером у экшен-игр - игр "на реакцию".
>>100090
Во-первых, нужно скукожить вьюпорт, не затрагивая рендеринг GUI:
https://docs.godotengine.org/en/stable/tutorials/3d/resolution_scaling.html
Открываешь "Project Settings > Rendering > Scaling 3D", там выбираешь:
>Mode = Nearest # чтоб "пиксели" не размазывало по экрану
>Scale = по вкусу: 0.5 (2x2), 0.3333 (3x3), 0.25 (4x4), 0.2 (5x5)...
Во-вторых, для кубиков и декораций на 3D сетке можно юзать GridMap:
https://docs.godotengine.org/en/stable/tutorials/3d/using_gridmaps.html
В-третьих, для "2.5D спрайтов" можно использовать ноду Sprite3D:
https://docs.godotengine.org/en/stable/classes/class_sprite3d.html
Настройки для начала можешь выбрать такие:
>billboard = billboard_fixed_y (чтоб смотрели в камеру)
>texture_filter = nearest (чтоб крупные пиксели были)
Также очень рекомендую заранее ознакомиться с SubViewport:
https://docs.godotengine.org/en/stable/tutorials/rendering/viewports.html
https://docs.godotengine.org/en/stable/tutorials/shaders/using_viewport_as_texture.html
Например, можно рендерить стопку из картинок в единственный Sprite3D:
>Sprite3D # что видим на экране, использует ViewportTexture
>_ SubViewport
>_ _ Sprite2D # голова
>_ _ Sprite2D # тело
>_ _ Sprite2D # оружие и т.п.
>_ _ AnimationPlayer и т.д.
Освещение и лампочки, скорее всего, самые обычные для 3D.
Текстуры в той игре сгенерированы нейронкой и/или сжаты.
Звучит сложно, но всё это делается в Godot за минуты...
>>100044
>Но в тоже время может передать погружение.
У тебя джва места для сидения:
1. В кресле приятно сидеть - утопаешь в его мягкости, аж в сон клонит.
2. На колышке неудобно сидеть - жопа болит, елозишь, ругаешься.
На каком "погрузишься", а на каком - "можешь погрузиться"?
Вопрос с подвохом. Думай.
>Почему редотики ничего не делают?
Потому что отвлекаюсь и трачу время на посты типа этого, а не на свои игры...
>>100110
Какая разница? Нравится ему такое - пусть дрочит. Бумер-шутеры же как-то взлетели - то есть нравятся людям...
>Зачем?
Какая разница? Нравится ему такое - пусть дрочит. Бумер-шутеры же как-то взлетели - то есть нравятся людям...
>>100094
Да я уже давно понял что тут нельзя поговорить за геймдизайн, сидят все те же ноулайферы как во всяких убежищах тешат свое самолюбие, коротают время, компенсируют социальную активность, вместо конструктивного диалога по теме. Ты вроде норм разговаривал, потом опять сорвался до "ряяяя"
Я спустя два-три месяца понял, что в игре с боевкой первое что нужно делать эту саму боевку, да вообще ключевую механику чтобы прочувствовать что до как будет в реальности. А ты в индустрии около десяти лет, делаешь в первую очередь арку ворот, завершение миссии, вырвиглазные блюры, майнкрафт местность с дикими переходами, бестолковую "дышащую" 2D idle анимацию спрайтов для плейсхолдеров. Из реального что тебе нужно сейчас - ты сделал только flood fill.
Вот и думай.
>Вопрос с подвохом. Думай.
Да я уже давно понял что тут нельзя поговорить за геймдизайн, сидят все те же ноулайферы как во всяких убежищах тешат свое самолюбие, коротают время, компенсируют социальную активность, вместо конструктивного диалога по теме. Ты вроде норм разговаривал, потом опять сорвался до "ряяяя"
>>Почему редотики ничего не делают?
>Потому что отвлекаюсь и трачу время на посты типа этого, а не на свои игры...
Я спустя два-три месяца понял, что в игре с боевкой первое что нужно делать эту саму боевку, да вообще ключевую механику чтобы прочувствовать что до как будет в реальности. А ты в индустрии около десяти лет, делаешь в первую очередь арку ворот, завершение миссии, вырвиглазные блюры, майнкрафт местность с дикими переходами, бестолковую "дышащую" 2D idle анимацию спрайтов для плейсхолдеров. Из реального что тебе нужно сейчас - ты сделал только flood fill.
Вот и думай.
369 Кб, mp4,600x600, 0:18
>>100297
Имеет ли смысл подробно расписывать очевидные вещи?..
Какая индустрия, это просто хобби. Я ни на что не рассчитываю.
А чего её делать, она и так известна. В Disgaea так и не играл? Ладно...
Вот я и сделал:
- нужно обязательно, ибо без "Game Over" это всё не игра, а песочница.
- нужны обязательно, такими я их и представлял, делается очень легко.
В общем, получилось, как я и планировал, поэтому и радуюсь этому.
Не блюр, а блум, и почему бы и нет? Это одна галочка в инспекторе...
Так я его по памяти набросал, потому что не разобрался, что лучше.
Кстати, спасибо, что напомнил - накинул движение по диагоналям.
>поговорить за геймдизайн
Имеет ли смысл подробно расписывать очевидные вещи?..
>ты в индустрии
Какая индустрия, это просто хобби. Я ни на что не рассчитываю.
>в игре с боевкой первое что нужно делать эту саму боевку
А чего её делать, она и так известна. В Disgaea так и не играл? Ладно...
>ключевую механику чтобы прочувствовать что до как будет в реальности
Вот я и сделал:
>арку ворот, завершение миссии
- нужно обязательно, ибо без "Game Over" это всё не игра, а песочница.
>майнкрафт местность с дикими переходами
>"дышащую" 2D idle анимацию спрайтов
- нужны обязательно, такими я их и представлял, делается очень легко.
В общем, получилось, как я и планировал, поэтому и радуюсь этому.
>вырвиглазные блюры
Не блюр, а блум, и почему бы и нет? Это одна галочка в инспекторе...
>Из реального что тебе нужно сейчас - ты сделал только flood fill.
Так я его по памяти набросал, потому что не разобрался, что лучше.
Кстати, спасибо, что напомнил - накинул движение по диагоналям.
>>100396
Ощущение закрытие гештальта в игре нужно геймеру, а не разработчику.
Меньше звезди, больше делай.
PS
Да, это ппц.
>- нужно обязательно, ибо без "Game Over" это всё не игра, а песочница.
Ощущение закрытие гештальта в игре нужно геймеру, а не разработчику.
Меньше звезди, больше делай.
PS
>блум
Да, это ппц.
>>100398
WAT? Игра литералли про то, как отправить команду придурочных ребят/девчат/монстров в некое очень неблагоприятное место и попытаться вывести их по возможности живыми и здоровыми, и с сувенирами. Наподобие сериала Stargate, но абсурдная комедия. Некоторые "миссии" могут вообще не иметь никаких противников и, следовательно, боестолкновений.
...а вообще, главная проблема в том, в какой момент позволять составлять отряд для отправки: когда ты посмотрел зону и знаешь, что в ней есть, когда лишь некоторые детали известны, или когда вообще нет информации? Полагаю, первый вариант уж слишком простой, а последний слишком хардкорный. Нужны промежуточные детали, типа "там очень холодно -> пригодятся герои с огненными способностями".
Я так не умею... Алсо на днях серьёзно заболел...
>Ощущение закрытие гештальта в игре
WAT? Игра литералли про то, как отправить команду придурочных ребят/девчат/монстров в некое очень неблагоприятное место и попытаться вывести их по возможности живыми и здоровыми, и с сувенирами. Наподобие сериала Stargate, но абсурдная комедия. Некоторые "миссии" могут вообще не иметь никаких противников и, следовательно, боестолкновений.
...а вообще, главная проблема в том, в какой момент позволять составлять отряд для отправки: когда ты посмотрел зону и знаешь, что в ней есть, когда лишь некоторые детали известны, или когда вообще нет информации? Полагаю, первый вариант уж слишком простой, а последний слишком хардкорный. Нужны промежуточные детали, типа "там очень холодно -> пригодятся герои с огненными способностями".
>Меньше звезди, больше делай.
Я так не умею... Алсо на днях серьёзно заболел...
>>100485
Если так хочется выводит годят из миссии - сделай широкую область высадки/эвакуации, а не ворота. Или же по краем карты области выхода.
Но все равно ты не то делаешь. Сделай сначала боевку, пару билдостроений и уже потом делай все остальное.
Если так хочется выводит годят из миссии - сделай широкую область высадки/эвакуации, а не ворота. Или же по краем карты области выхода.
Но все равно ты не то делаешь. Сделай сначала боевку, пару билдостроений и уже потом делай все остальное.
>>100574
Все он то делает.
Все он то делает.
>>100571
Это какой-то мем? У меня тут температура, голова, горло и суставы болят, сопли рекой текут и т.д. Это впервые за несколько лет (я ж дома сижу, от чего заболевать?) и именно тогда, когда я загорелся интересным проектом (впервые за... сколько?). Эх.
>>100574
В Disgaea DS это буквально 1 клеточка: клетку спавна возможно окружить 4 врагами и не давать игроку заспавнить больше 1 героя, а на клетке выхода очень часто находится неподвижный враг, у которого ещё и неуязвимость бывает из-за карты (нужно столкнуть). Однако, это всё компенсируется другими механиками, поэтому может не работать в другой игре. Посмотрим, нужно несколько вариантов попробовать сначала.
А я разве отказывался? Просто это не так-то просто организовать, оказывается. Каждой способности необходимы свои паттерны как в шахматах, и их необходимо накладывать на местность как будто это Тетрис, проверки всякие... Нужен генерализованный механизм, позволяющий вставлять новые атаки в существующую последовательность действий, без написания ad-hoc костылей на каждый паттерн... Нетривиальная штука по сравнению с шутанами.
Алсо, я не уверен, как генерализовать персонажей. Предполагается, что количество комбинаций может выходить за триллионы, т.е. делать по отдельности вообще не вариант. Нужно соединять компоненты. Непонятно только, какими они тут должны быть. Мне кажется, это важнее, чем паттерны атак...
Ладно, всё равно забью в скором времени (спойлер: ВНЕЗАПНО обнаружу, что моих скиллов рисования недостаточно, а все альтернативы не нравятся).
Это какой-то мем? У меня тут температура, голова, горло и суставы болят, сопли рекой текут и т.д. Это впервые за несколько лет (я ж дома сижу, от чего заболевать?) и именно тогда, когда я загорелся интересным проектом (впервые за... сколько?). Эх.
>>100574
>широкую область высадки/эвакуации
В Disgaea DS это буквально 1 клеточка: клетку спавна возможно окружить 4 врагами и не давать игроку заспавнить больше 1 героя, а на клетке выхода очень часто находится неподвижный враг, у которого ещё и неуязвимость бывает из-за карты (нужно столкнуть). Однако, это всё компенсируется другими механиками, поэтому может не работать в другой игре. Посмотрим, нужно несколько вариантов попробовать сначала.
>Сделай сначала боевку
А я разве отказывался? Просто это не так-то просто организовать, оказывается. Каждой способности необходимы свои паттерны как в шахматах, и их необходимо накладывать на местность как будто это Тетрис, проверки всякие... Нужен генерализованный механизм, позволяющий вставлять новые атаки в существующую последовательность действий, без написания ad-hoc костылей на каждый паттерн... Нетривиальная штука по сравнению с шутанами.
Алсо, я не уверен, как генерализовать персонажей. Предполагается, что количество комбинаций может выходить за триллионы, т.е. делать по отдельности вообще не вариант. Нужно соединять компоненты. Непонятно только, какими они тут должны быть. Мне кажется, это важнее, чем паттерны атак...
Ладно, всё равно забью в скором времени (спойлер: ВНЕЗАПНО обнаружу, что моих скиллов рисования недостаточно, а все альтернативы не нравятся).
>>100643
Это прям реальная херня. Как только появляется вдохновение возиться - вылезает какая-то проблема. Я уже даже не удивляюсь.
А если тратишь время на какую-то развлекательную чепуху - пожалуйста, деградируй.
>и именно тогда, когда я загорелся интересным проектом
Это прям реальная херня. Как только появляется вдохновение возиться - вылезает какая-то проблема. Я уже даже не удивляюсь.
А если тратишь время на какую-то развлекательную чепуху - пожалуйста, деградируй.
>>100643
По игре - сделай карточную боевку с синергией разных скиллов, сейчас это хит.
Slay the Spire - показал, что иногда можно забыть плейсхолдеры.
По игре - сделай карточную боевку с синергией разных скиллов, сейчас это хит.
Slay the Spire - показал, что иногда можно забыть плейсхолдеры.
28 Кб, 378x261Кто-нибудь ИТТ работал с XR Toolkit в ВР? Как сделать, чтобы игрок не проваливался через пол, если на полу нет коллайдера (мне нужна кастомная физика без встроенной гравитации)? И вообще найти подробный ман на move_and_slide(), а не те огрызки что на сайте. В XR режиме как будто живет своей жизнью, менять компоненты скорости вручную (в _physics_process()) бесполезно. Можно поставить Dummy physic engine на весь проект, но тогда отваливается перемещение, работает только поворот (даже если ставить velocity.x/z вручную).
>>100725
В Project Settings > Physics по-умолчанию стоят значения, чтобы всё вниз летело, убери их.
В Project Settings > Physics по-умолчанию стоят значения, чтобы всё вниз летело, убери их.
>>100725
Почему у тебя есть пол, но нет коллайдера?
Можешь просто исходники почитать:
https://github.com/godotengine/godot/blob/master/scene/3d/physics/character_body_3d.cpp#L43
Просто не юзай вектор гравитации. Вместо:
Делай так:
И тогда гравитация тебя не будет волновать.
Вариант А:
- удочеряешься от RigidBody3D
- ставишь галочку custom_integrator = true
- пишешь свою физику в _integrate_forces():
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-private-method-integrate-forces
Вариант Б:
- удочеряешься от PhysicsBody3D
- юзаешь test_move() для теста коллизий
- юзаешь move_and_collide() вместо move_and_slide()
- соскальзывания сам реализуешь (см. исходники)
https://docs.godotengine.org/en/stable/classes/class_physicsbody3d.html#class-physicsbody3d-method-move-and-collide
Может, это потому, что ты двигаешь XROrigin?
"Свою физику" ты обычно делаешь на базе какого-то существующего физического движка, в 3D Jolt будет оптимален, что-то другое тебе там выбирать не надо.
Почитай хотя бы начальные туториалы и поделай классические игры, прежде чем лезть в VR болото...
>>100733
Эта настройка влияет только на RigidBody...
>если на полу нет коллайдера
Почему у тебя есть пол, но нет коллайдера?
>найти подробный ман на move_and_slide()
Можешь просто исходники почитать:
https://github.com/godotengine/godot/blob/master/scene/3d/physics/character_body_3d.cpp#L43
>Как сделать, чтобы игрок не проваливался через пол, если на полу нет коллайдера
Просто не юзай вектор гравитации. Вместо:
>velocity = input × speed + gravity
>move_and_slide()
Делай так:
>velocity = input × speed
>move_and_slide()
И тогда гравитация тебя не будет волновать.
>кастомная физика без встроенной гравитации
Вариант А:
- удочеряешься от RigidBody3D
- ставишь галочку custom_integrator = true
- пишешь свою физику в _integrate_forces():
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-private-method-integrate-forces
Вариант Б:
- удочеряешься от PhysicsBody3D
- юзаешь test_move() для теста коллизий
- юзаешь move_and_collide() вместо move_and_slide()
- соскальзывания сам реализуешь (см. исходники)
https://docs.godotengine.org/en/stable/classes/class_physicsbody3d.html#class-physicsbody3d-method-move-and-collide
>В XR режиме как будто живет своей жизнью
Может, это потому, что ты двигаешь XROrigin?
>поставить Dummy physic engine на весь проект
"Свою физику" ты обычно делаешь на базе какого-то существующего физического движка, в 3D Jolt будет оптимален, что-то другое тебе там выбирать не надо.
Почитай хотя бы начальные туториалы и поделай классические игры, прежде чем лезть в VR болото...
>>100733
Эта настройка влияет только на RigidBody...
>>100725
Почему у тебя есть пол, но нет коллайдера?
Можешь просто исходники почитать:
https://github.com/godotengine/godot/blob/master/scene/3d/physics/character_body_3d.cpp#L43
Просто не юзай вектор гравитации. Вместо:
Делай так:
И тогда гравитация тебя не будет волновать.
Вариант А:
- удочеряешься от RigidBody3D
- ставишь галочку custom_integrator = true
- пишешь свою физику в _integrate_forces():
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-private-method-integrate-forces
Вариант Б:
- удочеряешься от PhysicsBody3D
- юзаешь test_move() для теста коллизий
- юзаешь move_and_collide() вместо move_and_slide()
- соскальзывания сам реализуешь (см. исходники)
https://docs.godotengine.org/en/stable/classes/class_physicsbody3d.html#class-physicsbody3d-method-move-and-collide
Может, это потому, что ты двигаешь XROrigin?
"Свою физику" ты обычно делаешь на базе какого-то существующего физического движка, в 3D Jolt будет оптимален, что-то другое тебе там выбирать не надо.
Почитай хотя бы начальные туториалы и поделай классические игры, прежде чем лезть в VR болото...
>>100733
Эта настройка влияет только на RigidBody...
>если на полу нет коллайдера
Почему у тебя есть пол, но нет коллайдера?
>найти подробный ман на move_and_slide()
Можешь просто исходники почитать:
https://github.com/godotengine/godot/blob/master/scene/3d/physics/character_body_3d.cpp#L43
>Как сделать, чтобы игрок не проваливался через пол, если на полу нет коллайдера
Просто не юзай вектор гравитации. Вместо:
>velocity = input × speed + gravity
>move_and_slide()
Делай так:
>velocity = input × speed
>move_and_slide()
И тогда гравитация тебя не будет волновать.
>кастомная физика без встроенной гравитации
Вариант А:
- удочеряешься от RigidBody3D
- ставишь галочку custom_integrator = true
- пишешь свою физику в _integrate_forces():
https://docs.godotengine.org/en/stable/classes/class_rigidbody3d.html#class-rigidbody3d-private-method-integrate-forces
Вариант Б:
- удочеряешься от PhysicsBody3D
- юзаешь test_move() для теста коллизий
- юзаешь move_and_collide() вместо move_and_slide()
- соскальзывания сам реализуешь (см. исходники)
https://docs.godotengine.org/en/stable/classes/class_physicsbody3d.html#class-physicsbody3d-method-move-and-collide
>В XR режиме как будто живет своей жизнью
Может, это потому, что ты двигаешь XROrigin?
>поставить Dummy physic engine на весь проект
"Свою физику" ты обычно делаешь на базе какого-то существующего физического движка, в 3D Jolt будет оптимален, что-то другое тебе там выбирать не надо.
Почитай хотя бы начальные туториалы и поделай классические игры, прежде чем лезть в VR болото...
>>100733
Эта настройка влияет только на RigidBody...
>>100665
Это какое-то издевательство над игроком, не? Игрок собирает хорошую колоду потом, кровью, гриндом и микротранзакциями, а RNG говорит: "неее, братишка, сегодня тебе выпадут все самые худшие карты, а вот противнику я выдам самые лучшие карты", и дальше остаётся только прокликивать до проигрыша. Так?
Случайный урон - это нормально: ты осознано кинул фаерболл против ледяного противника - из-за осечки получилось не так мощно, но всё-таки осмысленно, и следующий слабый фаерболл его уж точно добьёт. А случайные карты (приёмы) - это бред: перед тобой - ледяной противник, а из колоды вылезает "пописать водичкой" (+здоровье к ледяным монстрам), "пукнуть ветром" (у ледяных иммунитет), "отложить земляных кирпичей" (+защита от нападений из-под земли) - и ты закономерно огребаешь, а по чьей вине? По вине разработчика, что сделал несправедливую игру.
Пусть карты остаются у всяких там лудоманов и не усложняют и без того проблемный геймплей всех остальных возможных жанров видеоигр...
>карточные бои
Это какое-то издевательство над игроком, не? Игрок собирает хорошую колоду потом, кровью, гриндом и микротранзакциями, а RNG говорит: "неее, братишка, сегодня тебе выпадут все самые худшие карты, а вот противнику я выдам самые лучшие карты", и дальше остаётся только прокликивать до проигрыша. Так?
Случайный урон - это нормально: ты осознано кинул фаерболл против ледяного противника - из-за осечки получилось не так мощно, но всё-таки осмысленно, и следующий слабый фаерболл его уж точно добьёт. А случайные карты (приёмы) - это бред: перед тобой - ледяной противник, а из колоды вылезает "пописать водичкой" (+здоровье к ледяным монстрам), "пукнуть ветром" (у ледяных иммунитет), "отложить земляных кирпичей" (+защита от нападений из-под земли) - и ты закономерно огребаешь, а по чьей вине? По вине разработчика, что сделал несправедливую игру.
Пусть карты остаются у всяких там лудоманов и не усложняют и без того проблемный геймплей всех остальных возможных жанров видеоигр...
>>100781
да, но при грамотном дизайне, у игрока будет не ощущение нечестности, а ощущение "эх, почти, вот в новом забеге я уж точно затащу". рандом штука, которая работает иногда не твою пользу, а иногда очень даже в твою. это просто правила игры, которые ты принимаешь как данность. в остальном-то игра скилл бейсед, собрать правильный билд, найти интересные взаимодействия, даже правильно разыграть карты в одном ходу, так как иногда могут проглядываться неочевидные, но очень выгодные мувы. в том же StS я бывало вот прям сосал у босса, а потом переигрывал его несколько раз, находя более лучшие в долгосрок и краткосрок вещи, и в итоге побеждал. да, иногда всевозможные комбинации дают прогирыш, но это означает, что ты с самого начала значит не очень удачный билд собрал, так или иначе. конечно, бывают сиды, где и супер билда нет, и ивенты с картой говно, но это около границы нормального распределения шанс, вероятность мала, не повод отказываться от концепции рандомного-всего.
мимо
да, но при грамотном дизайне, у игрока будет не ощущение нечестности, а ощущение "эх, почти, вот в новом забеге я уж точно затащу". рандом штука, которая работает иногда не твою пользу, а иногда очень даже в твою. это просто правила игры, которые ты принимаешь как данность. в остальном-то игра скилл бейсед, собрать правильный билд, найти интересные взаимодействия, даже правильно разыграть карты в одном ходу, так как иногда могут проглядываться неочевидные, но очень выгодные мувы. в том же StS я бывало вот прям сосал у босса, а потом переигрывал его несколько раз, находя более лучшие в долгосрок и краткосрок вещи, и в итоге побеждал. да, иногда всевозможные комбинации дают прогирыш, но это означает, что ты с самого начала значит не очень удачный билд собрал, так или иначе. конечно, бывают сиды, где и супер билда нет, и ивенты с картой говно, но это около границы нормального распределения шанс, вероятность мала, не повод отказываться от концепции рандомного-всего.
мимо
>>100781
Как раз по теории геймдизайна, все ровно наоборот.
Из-за осечки не получилось - это выходной (output) рандом, игрок не может повлиять, просто смотрит в экран.
Карты пришли в руку - входной (input) рандом, игрок может совершать осознанные выборы, чтобы смягчить ситуацию (а еще он знает, какие карты скоро придут дальше).
https://www.youtube.com/watch?v=dwI5b-wRLic
Как раз по теории геймдизайна, все ровно наоборот.
Из-за осечки не получилось - это выходной (output) рандом, игрок не может повлиять, просто смотрит в экран.
Карты пришли в руку - входной (input) рандом, игрок может совершать осознанные выборы, чтобы смягчить ситуацию (а еще он знает, какие карты скоро придут дальше).
https://www.youtube.com/watch?v=dwI5b-wRLic
>>100798 >>100802
Тут вопрос не в том, "как бы добавить ещё больше рандома", а "сколько рандома - это уже перебор?"... Нужно смотреть игру в целом, оценивать риски, на которые идёт игрок, и нужно ли ему бОльше риска.
Например, если герои (колоды) умирают один раз и навсегда, риск у игрока изначально высок, и делать рандомную ловушку, которая убивает героя простым броском кубика, будет тупо жестоко/несправедливо. Соответственно, нужен бесконечный респавн/реролл ситуации, чтоб игроку "повезло в следующий раз". Но, допустим, в игре уже есть такая слот-машина, что приходится рероллить - зачем делать вторую?..
Этот риск закладывается в план. Вот допустим, минимальный урон =5, максимальный =10. Тогда противника со здоровьем в 50 очков можно убить, в наихудшем случае, за 10 ударов, а можно и за 5. Т.е. необходимо выдержать минимум 9 атак противника, ОДНАКО, есть шанс испытать всего лишь 4 атаки и победить, получив минимальный урон. Круто же!
Тут вопрос не в том, "как бы добавить ещё больше рандома", а "сколько рандома - это уже перебор?"... Нужно смотреть игру в целом, оценивать риски, на которые идёт игрок, и нужно ли ему бОльше риска.
Например, если герои (колоды) умирают один раз и навсегда, риск у игрока изначально высок, и делать рандомную ловушку, которая убивает героя простым броском кубика, будет тупо жестоко/несправедливо. Соответственно, нужен бесконечный респавн/реролл ситуации, чтоб игроку "повезло в следующий раз". Но, допустим, в игре уже есть такая слот-машина, что приходится рероллить - зачем делать вторую?..
>Из-за осечки не получилось
>игрок не может повлиять
Этот риск закладывается в план. Вот допустим, минимальный урон =5, максимальный =10. Тогда противника со здоровьем в 50 очков можно убить, в наихудшем случае, за 10 ударов, а можно и за 5. Т.е. необходимо выдержать минимум 9 атак противника, ОДНАКО, есть шанс испытать всего лишь 4 атаки и победить, получив минимальный урон. Круто же!
>>100809
не понял тебя. выше написали про StS, на что в ответ претензия, что рнг это издевательство над игроком, на что я ответил, что как раз StS очень удачный пример, что нет, не издевательство, а база.
ну так, StS так и разработан был.
не понял тебя. выше написали про StS, на что в ответ претензия, что рнг это издевательство над игроком, на что я ответил, что как раз StS очень удачный пример, что нет, не издевательство, а база.
>Этот риск закладывается в план.
ну так, StS так и разработан был.
>>100825
френдслопы
френдслопы
>>100825
асимптотически, что у тебя самого лучше получается и интересно, то и лучше, а так - кооп хоррор, инкрементал.
асимптотически, что у тебя самого лучше получается и интересно, то и лучше, а так - кооп хоррор, инкрементал.
>>100880
Микротранзакции можно в любую игру засунуть...
Микротранзакции можно в любую игру засунуть...
>>100861
плохо знаешь, карточки могут быть и в опен ворлд рпг. тем более я не предлагал их обязательное наличие, просто ответил на дурацкий пост, что карты это слишком рандомно и фу.
ну, так хотя бы кто-то вашу игру купит.
>Насколько я знаю, между ними ничего общего.
плохо знаешь, карточки могут быть и в опен ворлд рпг. тем более я не предлагал их обязательное наличие, просто ответил на дурацкий пост, что карты это слишком рандомно и фу.
>Предлагаешь анонам делать 1-в-1 клоны StS что ли?
ну, так хотя бы кто-то вашу игру купит.
>>100893
А где контр-аргумент, кроме "у StS как-то получилось (ЕСЛИ готов проходить одно и то же с нуля, надеясь, что рандом будет благосклонен в следующий раз"?
Ты только подтвердил, что карточки - это рандом.
Лол...
>карты это слишком рандомно
А где контр-аргумент, кроме "у StS как-то получилось (ЕСЛИ готов проходить одно и то же с нуля, надеясь, что рандом будет благосклонен в следующий раз"?
Ты только подтвердил, что карточки - это рандом.
>игру купит
Лол...
>>100899
я не отрицал существование рандома, а указывал на то, что его наличие не отменяет присутствие скилла в целом и что фукать в эту сторону - фу. рандом, подобный StS, это база геймдева.
ну, дяденьки у автоматов, которые дергают за канат, чтобы макака поймала банан, вроде готовы.
да лолкай на здоровье лол.
>Ты только подтвердил, что карточки - это рандом.
я не отрицал существование рандома, а указывал на то, что его наличие не отменяет присутствие скилла в целом и что фукать в эту сторону - фу. рандом, подобный StS, это база геймдева.
>ЕСЛИ готов проходить одно и то же с нуля, надеясь, что рандом будет благосклонен в следующий раз
ну, дяденьки у автоматов, которые дергают за канат, чтобы макака поймала банан, вроде готовы.
>Лол...
да лолкай на здоровье лол.
>>100953
С чего ты взял, что это ЦА? Нужно знать ЦА.
У тебя какое-то зашоренное видение рандома... Ты обнаружил рандом в StS в форме "карточек" (чисто визуальный элемент), и теперь уверен, что все игры обязательно должны включать в себя "карточки"?..
Рандом в синглплеерных играх нужен, поскольку без рандома игра будет проходиться одинаково. Если в стандартном шутере монстры прыгают из строго определённых позиций в определённое время, и ни монстры, ни оружие не добавляют случайности, весь геймплей будет сводиться к строго определённой и оптимальной последовательности действий, которую возможно заучить наизусть и исполнять как музыку. Интересно ли это игрокам? Большинству - нет, иначе занимались бы исполнением музыки, а не играми (существующие игры без рандома часто про музыку; геймплей синхронизируется с саундтреком и т.д.).
Но нужно ли добавлять рандом в шутер именно как случайные "карточки способностей"? Вот перед тобой монстр, а ты стоишь, выбираешь между "BFG9000" и "вскрикнуть и убежать", а потом тебе подкидывают перекачанного босса, а у тебя нет больше "BFG9000". Карточки здесь полностью нарушают жанр игры, т.е. лишают целевую аудиторию удовольствия от игры.
>дяденьки у автоматов
С чего ты взял, что это ЦА? Нужно знать ЦА.
>рандом, подобный StS, это база геймдева
У тебя какое-то зашоренное видение рандома... Ты обнаружил рандом в StS в форме "карточек" (чисто визуальный элемент), и теперь уверен, что все игры обязательно должны включать в себя "карточки"?..
Рандом в синглплеерных играх нужен, поскольку без рандома игра будет проходиться одинаково. Если в стандартном шутере монстры прыгают из строго определённых позиций в определённое время, и ни монстры, ни оружие не добавляют случайности, весь геймплей будет сводиться к строго определённой и оптимальной последовательности действий, которую возможно заучить наизусть и исполнять как музыку. Интересно ли это игрокам? Большинству - нет, иначе занимались бы исполнением музыки, а не играми (существующие игры без рандома часто про музыку; геймплей синхронизируется с саундтреком и т.д.).
Но нужно ли добавлять рандом в шутер именно как случайные "карточки способностей"? Вот перед тобой монстр, а ты стоишь, выбираешь между "BFG9000" и "вскрикнуть и убежать", а потом тебе подкидывают перекачанного босса, а у тебя нет больше "BFG9000". Карточки здесь полностью нарушают жанр игры, т.е. лишают целевую аудиторию удовольствия от игры.
>>100825
Инкрементальный дэкбилдер-автошутер.
Инкрементальный дэкбилдер-автошутер.
А вы как организуете игру (переключением сцен или с MAIN нодой)?
https://www.youtube.com/watch?v=a4rBBP3UBow
https://www.youtube.com/watch?v=a4rBBP3UBow
>>101257
Main нода, в ней подгружаемые-заменяемые контейнеры на элементы игры, уровни, уй и прочее. Видос не смотрел.
Main нода, в ней подгружаемые-заменяемые контейнеры на элементы игры, уровни, уй и прочее. Видос не смотрел.
277 Кб, 1619x815>>101310
чювак я же смог своих нарисовать и ты своих уродов нарисуешь, помоему не важно как они выглядят а главное создать базу механик а уже потом если механики работают можно и художника нанять
чювак я же смог своих нарисовать и ты своих уродов нарисуешь, помоему не важно как они выглядят а главное создать базу механик а уже потом если механики работают можно и художника нанять
2,3 Мб, 1898x961а вообще пока не могу понять как должная сцена битвы выглядеть
мне видится что важно отображать информацию про обоих персонажей и игрока и врага так так как как они сами по сути одинаковые только разница в том кто управляет
и вот хз должно ли это в таком виде выглядеть или странным кажется?
мне видится что важно отображать информацию про обоих персонажей и игрока и врага так так как как они сами по сути одинаковые только разница в том кто управляет
и вот хз должно ли это в таком виде выглядеть или странным кажется?
>>101310
Ты скорее всего утратил мотивацию, а мозг логично подобрал причину (мозги любят завуалировать).
Не планируй, не думай, просто открывай проект каждый день и копошись. Делай что любишь - создавай миры. Похер на сравнение или оценку, похер на план, просто кайфуй с чего кайфовал раньше.
Ты скорее всего утратил мотивацию, а мозг логично подобрал причину (мозги любят завуалировать).
Не планируй, не думай, просто открывай проект каждый день и копошись. Делай что любишь - создавай миры. Похер на сравнение или оценку, похер на план, просто кайфуй с чего кайфовал раньше.
>>101310
>>101340
Я сейчас даже на спрайты подзабил (заипался рисовать и потом дропать), буду делать что-то на уровне таких форм
>>1096462 →
Вы думали это корабль? НЕТ! Это ковбой ёптить.
>>101340
Я сейчас даже на спрайты подзабил (заипался рисовать и потом дропать), буду делать что-то на уровне таких форм
>>1096462 →
Вы думали это корабль? НЕТ! Это ковбой ёптить.
>>101327
Норм, добавь анимации удара (например взмах меча) и слегка двигай спрайт юнита. Будет уже норм смотреться
>и вот хз должно ли это в таком виде выглядеть или странным кажется?
Норм, добавь анимации удара (например взмах меча) и слегка двигай спрайт юнита. Будет уже норм смотреться
>>101327
Попробуй использовать PanelContainer с рамками. Я бы раскидал их в разные углы экрана, чтобы не слипались.
Алсо, увеличь им лбы. Аниме-глаза растягиваются вниз, а не вверх, начинаясь примерно с середины лица.
Попробуй использовать PanelContainer с рамками. Я бы раскидал их в разные углы экрана, чтобы не слипались.
Алсо, увеличь им лбы. Аниме-глаза растягиваются вниз, а не вверх, начинаясь примерно с середины лица.
214 Кб, mp4,700x394, 0:10
>>101344
Что-то типа из этого рода. Помни только от ярких вспышек/всплесков люди могут быстро уставать.
> добавь анимации удара
Что-то типа из этого рода. Помни только от ярких вспышек/всплесков люди могут быстро уставать.
7,9 Мб, mp4,1280x720, 1:16
>>101317
Спасибо, благодаря тебе я решился на идею с чиби-фишками. А то ломал голову над тем, как же вписать в рамки 1x1x2м героев с разными габаритами так, чтоб это не выглядело слишком тупо.
>>101340
Мне в голову постоянно то порнуха какая-то лезет, то какая-то кринжатина - показывать другим людям стыдно. Но показывать что-то кому-то хочется, иначе зачем это всё? Нет мотивации сидеть и делать что-то творческое в стол, не имея надежды кому-либо это всё продемонстрировать.
>>101342
Вкатился в 3D, когда понял, что для 2D мои руки слишком неточные (не могу ни одной нужной линии провести), но решил попытаться-таки подкачать скилл в 2D, потому что 3D из фантазии совсем без хотя бы эскизов делать слишком трудно, но рисовать случайные картинки - скучно, поэтому начал думать над тем, какую игру можно сделать, но только так, чтобы это была не порнуха... И вспомнил про этот проект - подумалось, можно переделать на 2.5D пошаговую тактику, используя плоские картинки вместо моделек. В итоге я неделю не притрагивался к рисованию, потому что ковырялся в редакторе сцен и кода, а потом слёг с температурой.
Спасибо, благодаря тебе я решился на идею с чиби-фишками. А то ломал голову над тем, как же вписать в рамки 1x1x2м героев с разными габаритами так, чтоб это не выглядело слишком тупо.
>>101340
>Делай что любишь - создавай миры
Мне в голову постоянно то порнуха какая-то лезет, то какая-то кринжатина - показывать другим людям стыдно. Но показывать что-то кому-то хочется, иначе зачем это всё? Нет мотивации сидеть и делать что-то творческое в стол, не имея надежды кому-либо это всё продемонстрировать.
>>101342
>Пробовал сначала замоделить
Вкатился в 3D, когда понял, что для 2D мои руки слишком неточные (не могу ни одной нужной линии провести), но решил попытаться-таки подкачать скилл в 2D, потому что 3D из фантазии совсем без хотя бы эскизов делать слишком трудно, но рисовать случайные картинки - скучно, поэтому начал думать над тем, какую игру можно сделать, но только так, чтобы это была не порнуха... И вспомнил про этот проект - подумалось, можно переделать на 2.5D пошаговую тактику, используя плоские картинки вместо моделек. В итоге я неделю не притрагивался к рисованию, потому что ковырялся в редакторе сцен и кода, а потом слёг с температурой.
>>101716
Ты уже ограничил себя размером тайла, такими вот стройными персонажами. Плоска поверхность позволяет натянуть жирного монстра в 1.2-1.5 размера, а тут нет.
Идея фишек - хорошая, смотри как интересно сделали в battle brothers. Экономия в пол тела, фишки жирные помещается любой арт.
Местность хорошая, если бы по разным сторонам стреляли какие-то пушки/танки - что-то с баллистикой (и явным видимым полетом). Туда же авиацию. Но не делай симулятор ходьбы (пустых передвижений) в тактической карте.
Мне думается без скилла в 2Д там все равно делать нечего. Ощущение перспективы (да, да, даже в 3Д) и пропорций - это надо все равно тренировать (даже если по рефу делаешь). Я 3д обхожу стороной, потому что ощущаю что работы больше и еще практика показала что плохое 2д смотрится лучше чем плохое лоуполи 3д.
Ты недавно в интернете? Хотя с порно не советую работать.
Ты уже ограничил себя размером тайла, такими вот стройными персонажами. Плоска поверхность позволяет натянуть жирного монстра в 1.2-1.5 размера, а тут нет.
Идея фишек - хорошая, смотри как интересно сделали в battle brothers. Экономия в пол тела, фишки жирные помещается любой арт.
Местность хорошая, если бы по разным сторонам стреляли какие-то пушки/танки - что-то с баллистикой (и явным видимым полетом). Туда же авиацию. Но не делай симулятор ходьбы (пустых передвижений) в тактической карте.
>3D
Мне думается без скилла в 2Д там все равно делать нечего. Ощущение перспективы (да, да, даже в 3Д) и пропорций - это надо все равно тренировать (даже если по рефу делаешь). Я 3д обхожу стороной, потому что ощущаю что работы больше и еще практика показала что плохое 2д смотрится лучше чем плохое лоуполи 3д.
>Мне в голову постоянно то порнуха какая-то лезет, то какая-то кринжатина - показывать другим людям стыдно
Ты недавно в интернете? Хотя с порно не советую работать.
Ещё часы прикольные накидал - давно хотел такое.
>>101717
Написал длинный ответ, но стало стыдно, удалил.
В общем, просто знай, что у меня своя задумка.
Обычно всё в точности наоборот же...
>>101717
Написал длинный ответ, но стало стыдно, удалил.
В общем, просто знай, что у меня своя задумка.
>плохое 2д смотрится лучше чем плохое 3д
Обычно всё в точности наоборот же...
CharacterBody2D::get_slide_collision_count()
Почему при быстрых скоростях эта штука дает 0, но обсчитывает столкновение (объект честно отлетает)?
1) Используется в func _physics_process()
2) 60fps
3) стоит после move_and_slide()
Есть способ обсчитать столкновение двух CharacterBody2D, без создание еще одного коллайдера с Area2D и сигналом?
Почему при быстрых скоростях эта штука дает 0, но обсчитывает столкновение (объект честно отлетает)?
1) Используется в func _physics_process()
2) 60fps
3) стоит после move_and_slide()
Есть способ обсчитать столкновение двух CharacterBody2D, без создание еще одного коллайдера с Area2D и сигналом?
>>101778
В общем, если объект стоит, иногда (по фазе луны, или положению юпитера) get_slide_collision_count у стоящего объекта может вернуть 0 (но чаще больше 0)
Живите с этим.
В общем, если объект стоит, иногда (по фазе луны, или положению юпитера) get_slide_collision_count у стоящего объекта может вернуть 0 (но чаще больше 0)
Живите с этим.
>>097332 (OP)
Что то не запускались проекты на старых Андроидах >12 ,откатился на 4.6.3, - норм стало.
>4.7.1
Что то не запускались проекты на старых Андроидах >12 ,откатился на 4.6.3, - норм стало.
>>101968
Там, скорее всего, подняли Android target SDK для соотвтетствия тому, что принимают в гугл плей. Вроде бы теперь это Android 16 и AAB вместо APK.
https://forum.godotengine.org/t/how-to-target-latest-android-sdk/142631
Там где-то ручками можно выбрать, минимальный поддерживаемый это Android 5.
Там, скорее всего, подняли Android target SDK для соотвтетствия тому, что принимают в гугл плей. Вроде бы теперь это Android 16 и AAB вместо APK.
https://forum.godotengine.org/t/how-to-target-latest-android-sdk/142631
Там где-то ручками можно выбрать, минимальный поддерживаемый это Android 5.
Я устал делать игры
>>101778 >>101801
Что с чем ты сталкиваешь? Два CharacterBody, один из которых стоит на месте? И тот, который быстро двигается, отскакивает/меняет направление, а тот, который стоял на месте, остаётся стоять на месте? Или оба отскакивают?..
Суть в том, что CharacterBody сам по себе не толкает другие объекты, он только "создаёт препятствие" на пути других объектов (которое выглядит для этих объектов как неподвижный StaticBody), и если эти другие объекты задетектят препятствие, то они могут подвинуться. Но препятствие создаётся только когда CharacterBody реально останавливается, а скольжение/отскоки происходят как бы "в уме", то есть получается так:
1. CharacterBody размером N двигается с большой скоростью, покрывая N10 пикселей за тик.
2. CharacterBody видит препятствие на расстоянии N5 от него, и сразу вычисляет отскок на N5.
3. Для того препятствия, этот CharacterBody никогда не касался его, и даже не стоял рядом.
Если ты хочешь надёжно толкать объекты своим CharacterBody, тогда ты должен детектить столкновения на стороне CharacterBody и отправлять запрос типа apply_impulse тем объектам, с которыми ты столкнулся, будь то RigidBody или CharacterBody (последним придётся свой метод сделать - рекомендую использовать то же имя, что и у RigidBody, чтоб заюзать duck typing).
Алсо, если ты там что-то вроде бильярда делаешь, то лучше используй RigidBody - там уже все отскоки и движение по траекториям сделаны за тебя. CharacterBody имеет смысл только для персонажей, которые твёрдо стоят на ногах и не толкают телом других персонажей.
Что с чем ты сталкиваешь? Два CharacterBody, один из которых стоит на месте? И тот, который быстро двигается, отскакивает/меняет направление, а тот, который стоял на месте, остаётся стоять на месте? Или оба отскакивают?..
Суть в том, что CharacterBody сам по себе не толкает другие объекты, он только "создаёт препятствие" на пути других объектов (которое выглядит для этих объектов как неподвижный StaticBody), и если эти другие объекты задетектят препятствие, то они могут подвинуться. Но препятствие создаётся только когда CharacterBody реально останавливается, а скольжение/отскоки происходят как бы "в уме", то есть получается так:
1. CharacterBody размером N двигается с большой скоростью, покрывая N10 пикселей за тик.
2. CharacterBody видит препятствие на расстоянии N5 от него, и сразу вычисляет отскок на N5.
3. Для того препятствия, этот CharacterBody никогда не касался его, и даже не стоял рядом.
Если ты хочешь надёжно толкать объекты своим CharacterBody, тогда ты должен детектить столкновения на стороне CharacterBody и отправлять запрос типа apply_impulse тем объектам, с которыми ты столкнулся, будь то RigidBody или CharacterBody (последним придётся свой метод сделать - рекомендую использовать то же имя, что и у RigidBody, чтоб заюзать duck typing).
Алсо, если ты там что-то вроде бильярда делаешь, то лучше используй RigidBody - там уже все отскоки и движение по траекториям сделаны за тебя. CharacterBody имеет смысл только для персонажей, которые твёрдо стоят на ногах и не толкают телом других персонажей.
>>102009
Я могу быстро вычленить демку, скажи как подготовить (удалить просто ".godot" и все поместить в архив или еще что-то нужно?). У меня 4.7.1
Проблема текстом:
Два CharacterBody2D
I) A - стоит (может двигаться, но стоит по условию), в нём детектим (get_slide_collision_count) столкновение, он не отскакивает
II) Б - двигается все время на A.
III) Логика такая - в A мы проверяем get_slide_collision_count и удаляем Б. (я случайно сделал так для отладки и поймал эту багу)
Что происходит
1) Небольшая скорость - все работает норм A детектит Б всегда, get_slide_collision_count() > 0
2) Высокая скорость (появление проблемы) - все работает как при 1 случае, но иногда (примерно 1 из 10) - Б сталкивается с A, но get_slide_collision_count == 0 и он не удаляется, при этом отскакивает от А.
Коллизия такая
name::Layer/Mask
A::1/2
Б::2/1
Еще у меня у меня везде CollisionPolygon2D с острой мордочкой (мне кажется что-то связанно с этим тоже).
В чем реальная ошибка - отскок (bounce) Б от А происходит, то есть движок определяет коллизию, но указывает в get_slide_collision_count == 0
Как-будто есть две отдельные логики на условие столкновение и формирование объектов столкновения (например какой-то угол меньше чем нужно и get_slide_collision_count затирается со всеми объектами).
Звучит так что надо уже ишью оформить или залесть в сорцы, но мне чет лень так (да и мне кажется я что-то не понимаю или ошибся и не вижу).
В общем, про демку скажи, я подготовлю и скину (там не долго).
>Что с чем ты сталкиваешь? Два CharacterBody, один из которых стоит на месте? И тот, который быстро двигается, отскакивает/меняет направление, а тот, который стоял на месте, остаётся стоять на месте? Или оба отскакивают?..
Я могу быстро вычленить демку, скажи как подготовить (удалить просто ".godot" и все поместить в архив или еще что-то нужно?). У меня 4.7.1
Проблема текстом:
Два CharacterBody2D
I) A - стоит (может двигаться, но стоит по условию), в нём детектим (get_slide_collision_count) столкновение, он не отскакивает
II) Б - двигается все время на A.
III) Логика такая - в A мы проверяем get_slide_collision_count и удаляем Б. (я случайно сделал так для отладки и поймал эту багу)
Что происходит
1) Небольшая скорость - все работает норм A детектит Б всегда, get_slide_collision_count() > 0
2) Высокая скорость (появление проблемы) - все работает как при 1 случае, но иногда (примерно 1 из 10) - Б сталкивается с A, но get_slide_collision_count == 0 и он не удаляется, при этом отскакивает от А.
Коллизия такая
name::Layer/Mask
A::1/2
Б::2/1
Еще у меня у меня везде CollisionPolygon2D с острой мордочкой (мне кажется что-то связанно с этим тоже).
В чем реальная ошибка - отскок (bounce) Б от А происходит, то есть движок определяет коллизию, но указывает в get_slide_collision_count == 0
Как-будто есть две отдельные логики на условие столкновение и формирование объектов столкновения (например какой-то угол меньше чем нужно и get_slide_collision_count затирается со всеми объектами).
Звучит так что надо уже ишью оформить или залесть в сорцы, но мне чет лень так (да и мне кажется я что-то не понимаю или ошибся и не вижу).
В общем, про демку скажи, я подготовлю и скину (там не долго).
>>102009
Я могу быстро вычленить демку, скажи как подготовить (удалить просто ".godot" и все поместить в архив или еще что-то нужно?). У меня 4.7.1
Проблема текстом:
Два CharacterBody2D
I) A - стоит (может двигаться, но стоит по условию), в нём детектим (get_slide_collision_count) столкновение, он не отскакивает
II) Б - двигается все время на A.
III) Логика такая - в A мы проверяем get_slide_collision_count и удаляем Б. (я случайно сделал так для отладки и поймал эту багу)
Что происходит
1) Небольшая скорость - все работает норм A детектит Б всегда, get_slide_collision_count() > 0
2) Высокая скорость (появление проблемы) - все работает как при 1 случае, но иногда (примерно 1 из 10) - Б сталкивается с A, но get_slide_collision_count == 0 и он не удаляется, при этом отскакивает от А.
Коллизия такая
name::Layer/Mask
A::1/2
Б::2/1
Еще у меня у меня везде CollisionPolygon2D с острой мордочкой (мне кажется что-то связанно с этим тоже).
В чем реальная ошибка - отскок (bounce) Б от А происходит, то есть движок определяет коллизию, но указывает в get_slide_collision_count == 0
Как-будто есть две отдельные логики на условие столкновение и формирование объектов столкновения (например какой-то угол меньше чем нужно и get_slide_collision_count затирается со всеми объектами).
Звучит так что надо уже ишью оформить или залесть в сорцы, но мне чет лень так (да и мне кажется я что-то не понимаю или ошибся и не вижу).
В общем, про демку скажи, я подготовлю и скину (там не долго).
>Что с чем ты сталкиваешь? Два CharacterBody, один из которых стоит на месте? И тот, который быстро двигается, отскакивает/меняет направление, а тот, который стоял на месте, остаётся стоять на месте? Или оба отскакивают?..
Я могу быстро вычленить демку, скажи как подготовить (удалить просто ".godot" и все поместить в архив или еще что-то нужно?). У меня 4.7.1
Проблема текстом:
Два CharacterBody2D
I) A - стоит (может двигаться, но стоит по условию), в нём детектим (get_slide_collision_count) столкновение, он не отскакивает
II) Б - двигается все время на A.
III) Логика такая - в A мы проверяем get_slide_collision_count и удаляем Б. (я случайно сделал так для отладки и поймал эту багу)
Что происходит
1) Небольшая скорость - все работает норм A детектит Б всегда, get_slide_collision_count() > 0
2) Высокая скорость (появление проблемы) - все работает как при 1 случае, но иногда (примерно 1 из 10) - Б сталкивается с A, но get_slide_collision_count == 0 и он не удаляется, при этом отскакивает от А.
Коллизия такая
name::Layer/Mask
A::1/2
Б::2/1
Еще у меня у меня везде CollisionPolygon2D с острой мордочкой (мне кажется что-то связанно с этим тоже).
В чем реальная ошибка - отскок (bounce) Б от А происходит, то есть движок определяет коллизию, но указывает в get_slide_collision_count == 0
Как-будто есть две отдельные логики на условие столкновение и формирование объектов столкновения (например какой-то угол меньше чем нужно и get_slide_collision_count затирается со всеми объектами).
Звучит так что надо уже ишью оформить или залесть в сорцы, но мне чет лень так (да и мне кажется я что-то не понимаю или ошибся и не вижу).
В общем, про демку скажи, я подготовлю и скину (там не долго).
492 Кб, mp4,1008x566, 0:34
>>102055
>>102009
Проще скинуть демку.
Взрывы это смерть по таймауту 4 секунды, чтобы они орбитами как планеты не летали. Ограничил количество 5 штуками.
Дольше искал файлообменник, надеюсь норм.
https://transfiles.ru/t7l2t
>>102009
Проще скинуть демку.
Взрывы это смерть по таймауту 4 секунды, чтобы они орбитами как планеты не летали. Ограничил количество 5 штуками.
Дольше искал файлообменник, надеюсь норм.
https://transfiles.ru/t7l2t
>>102009
Теперь, кажется, понимаю как работает. Если что поправь.
Если оба А и Б CharacterBody
Если Б движется и вычисляется отскок с А (сам А неподвижен), то состояния будет такие:
А::get_slide_collision_count == 0 // ничего не узнает
Б::get_slide_collision_count == 1 // посчитал, добавил но никому не сообщил об столкновение.
Как вариант передавать друг другу импульсы?
>2. CharacterBody видит препятствие на расстоянии N5 от него, и сразу вычисляет отскок на N5.
>3. Для того препятствия, этот CharacterBody никогда не касался его, и даже не стоял рядом.
Теперь, кажется, понимаю как работает. Если что поправь.
Если оба А и Б CharacterBody
Если Б движется и вычисляется отскок с А (сам А неподвижен), то состояния будет такие:
А::get_slide_collision_count == 0 // ничего не узнает
Б::get_slide_collision_count == 1 // посчитал, добавил но никому не сообщил об столкновение.
Как вариант передавать друг другу импульсы?
>>102066
В общем. У меня есть персонаж, на него бежит волк, в моменте волк совершает прыжок и сталкивается с персонажем - я хочу чтобы волк толкнул игрока и сам отреагировал по массе.
Мне нужно
1) Передавать друг другу импульсы и рассчитывать самому импульс (масса на скорость)
2) Заменить волка на RigidBody?
3) Заменить и волка и персонажа на RigidBody (чтобы само считалось)?
Я примерно понимаю как можно рассчитать все искусственно, но хочу максимально задействовать физику годота, чтобы волк даже массу пуль чувствовал (они его немного тормозили)
В общем. У меня есть персонаж, на него бежит волк, в моменте волк совершает прыжок и сталкивается с персонажем - я хочу чтобы волк толкнул игрока и сам отреагировал по массе.
Мне нужно
1) Передавать друг другу импульсы и рассчитывать самому импульс (масса на скорость)
2) Заменить волка на RigidBody?
3) Заменить и волка и персонажа на RigidBody (чтобы само считалось)?
Я примерно понимаю как можно рассчитать все искусственно, но хочу максимально задействовать физику годота, чтобы волк даже массу пуль чувствовал (они его немного тормозили)
>>102060
Ты навайбкодил нейронкой что-то, что сам не понимаешь, а теперь просишь анонов из треда разобраться?
>>102067
Это крайне глупая затея. GodotPhysics(2D/3D) писали из-за синдрома Not Invented Here и поддерживают только потому, что многие юзеры привязались к этому решению. Движки физики самого Godot очень медленные и уж слишком неточные/нестабильные. Вон, для новых проектов 3D физикой автоматически выбирается Jolt, что и быстрее, и точнее/стабильнее. Для 2D тоже есть альтернативы, но нужно скачивать отдельно, если нужно.
Более того, в геймдеве крайне редко бывает универсальное решение, которое подходило бы всем играм, да и в отдельно взятой игре часто получается так, что нельзя написать универсальный компонент. Поэтому геймдев - это самая костыльно-велосипедная часть айти. Если тебе нужно решить задачу "ловить снаряды лицом мелкого кораблика", то ты можешь навесить круглую Area2D вокруг корабля, ограничить максимальную скорость, и потом экспериментальным путём подогнать параметры так, чтобы глюков было, скажем, менее 1 на 100 попыток. А можешь сделать как-то по-другому - какая разница? Твоя игра - тебе решать.
Просто имей в виду, что если ты сегодня делаешь клон Asteroids, а завтра хочешь сделать каких-то "волков, прыгающих через игрока", тебе, скорее всего, придётся перестраивать кучу сцен и переписывать кучу кода, а потом снова подгонять параметры, потому что это будет уже совсем другая игра с другими ощущениями. Определись сначала с игрой, потом уже пиши костыли и велосипеды под эту конкретную игру. Не можешь определиться с игрой? Делай прототипы - прототипам можно быть глючными и ненадёжными, потому что ты их всё равно никому не дашь. Если прототип играется норм (закрывая глаза на глюки), тогда переписывай заново, используя полученные знания и опыт для создания оптимальных костылей и велосипедов. Вот и весь секрет.
Ты навайбкодил нейронкой что-то, что сам не понимаешь, а теперь просишь анонов из треда разобраться?
>>102067
>хочу максимально задействовать физику годота
Это крайне глупая затея. GodotPhysics(2D/3D) писали из-за синдрома Not Invented Here и поддерживают только потому, что многие юзеры привязались к этому решению. Движки физики самого Godot очень медленные и уж слишком неточные/нестабильные. Вон, для новых проектов 3D физикой автоматически выбирается Jolt, что и быстрее, и точнее/стабильнее. Для 2D тоже есть альтернативы, но нужно скачивать отдельно, если нужно.
Более того, в геймдеве крайне редко бывает универсальное решение, которое подходило бы всем играм, да и в отдельно взятой игре часто получается так, что нельзя написать универсальный компонент. Поэтому геймдев - это самая костыльно-велосипедная часть айти. Если тебе нужно решить задачу "ловить снаряды лицом мелкого кораблика", то ты можешь навесить круглую Area2D вокруг корабля, ограничить максимальную скорость, и потом экспериментальным путём подогнать параметры так, чтобы глюков было, скажем, менее 1 на 100 попыток. А можешь сделать как-то по-другому - какая разница? Твоя игра - тебе решать.
Просто имей в виду, что если ты сегодня делаешь клон Asteroids, а завтра хочешь сделать каких-то "волков, прыгающих через игрока", тебе, скорее всего, придётся перестраивать кучу сцен и переписывать кучу кода, а потом снова подгонять параметры, потому что это будет уже совсем другая игра с другими ощущениями. Определись сначала с игрой, потом уже пиши костыли и велосипеды под эту конкретную игру. Не можешь определиться с игрой? Делай прототипы - прототипам можно быть глючными и ненадёжными, потому что ты их всё равно никому не дашь. Если прототип играется норм (закрывая глаза на глюки), тогда переписывай заново, используя полученные знания и опыт для создания оптимальных костылей и велосипедов. Вот и весь секрет.
>>102067
Впрочем, извини, если что. Я в плохом настроении.
У тебя сейчас игра в 2D с видом сверху - как прыжок будешь делать? Можно симулировать через масштаб (scale), но нужно быть аккуратнее с физикой (уже не помню, какие проблемы могут быть, но я делал так).
Это самое очевидное, если тебя устраивает движение со скольжением. Поиграйся с linear_damp и angular_damp, чтобы сделать персонажа чуть более отзывчивым, или сделай аналог этих свойств в своём коде.
Впрочем, извини, если что. Я в плохом настроении.
>волк совершает прыжок
У тебя сейчас игра в 2D с видом сверху - как прыжок будешь делать? Можно симулировать через масштаб (scale), но нужно быть аккуратнее с физикой (уже не помню, какие проблемы могут быть, но я делал так).
>Заменить и волка и персонажа на RigidBody
Это самое очевидное, если тебя устраивает движение со скольжением. Поиграйся с linear_damp и angular_damp, чтобы сделать персонажа чуть более отзывчивым, или сделай аналог этих свойств в своём коде.
709 Кб, 736x762>>102069
Фига ты дебил, ты хоть открывал? Там кода на 5-10 минут.
Это так называемый playgrоund, проекты "огрызки" для тестов чего-либо. Я поймал проблему у себя в проекте, начал чистить, понял что вилкой ничего не почищу, пошел воспроизвел в playground.
Нигде не написано что во время bounce не передает информацию с тем чем взаимодействует. Может в геймдеве это норм, но с точки зрения архитектуры это немного костыль (ты уже просчитал взаимодействие - почему бы ему не дать инфу о коллизии, которая в сравнение с расчетом уже бесплатная).
Я у себя давно уже переделал под арену, но мне хотелось понять почему так происходит. Но ты вместо ответа додумал свое и сам с этого взорвался. Я вообще не вайбкожу, но использую иногда ИИ для обучения, он хорошо показываеn "best practice".
PS волка не покажу.
>Ты навайбкодил нейронкой что-то, что сам не понимаешь, а теперь просишь анонов из треда разобраться?
Фига ты дебил, ты хоть открывал? Там кода на 5-10 минут.
Это так называемый playgrоund, проекты "огрызки" для тестов чего-либо. Я поймал проблему у себя в проекте, начал чистить, понял что вилкой ничего не почищу, пошел воспроизвел в playground.
Нигде не написано что во время bounce не передает информацию с тем чем взаимодействует. Может в геймдеве это норм, но с точки зрения архитектуры это немного костыль (ты уже просчитал взаимодействие - почему бы ему не дать инфу о коллизии, которая в сравнение с расчетом уже бесплатная).
Я у себя давно уже переделал под арену, но мне хотелось понять почему так происходит. Но ты вместо ответа додумал свое и сам с этого взорвался. Я вообще не вайбкожу, но использую иногда ИИ для обучения, он хорошо показываеn "best practice".
PS волка не покажу.
487 Кб, 700x466>>102070
Мы же не фулл top, мы как-будто смотрим на мир под углом. Даже в римке есть перспектива и объем (художник местами передал один и тот же "угол", а есть старые спрайты фиг пойми в какой проекции, наверное еще сам гений рисовал).
-Волк движется - скорость 1х
-Становиться близко, рывок - скорость 10х
-Можно даже слегка анимировать спрайт (поднять слегка в самом начале и опустить конце).
>У тебя сейчас игра в 2D с видом сверху - как прыжок будешь делать?
Мы же не фулл top, мы как-будто смотрим на мир под углом. Даже в римке есть перспектива и объем (художник местами передал один и тот же "угол", а есть старые спрайты фиг пойми в какой проекции, наверное еще сам гений рисовал).
-Волк движется - скорость 1х
-Становиться близко, рывок - скорость 10х
-Можно даже слегка анимировать спрайт (поднять слегка в самом начале и опустить конце).
>>102084
Пример до и после.
Если вы стеснялись своих плейсхолдеров, эти спрайты заработали 55 000$ за 8 дней (14 500$ за первый день).
>(художник местами передал один и тот же "угол", а есть старые спрайты фиг пойми в какой проекции, наверное еще сам гений рисовал)
Пример до и после.
Если вы стеснялись своих плейсхолдеров, эти спрайты заработали 55 000$ за 8 дней (14 500$ за первый день).
>>102055
Так это абсолютно нормально, прочитай что написано в доках про get_slide_collision_count. Оно возвращает счет коллизий, возникших в последний вызов move_and_slide. move_and_slide пытается сдвинуть тело на скорость*дельта, если у него не получается, он записывает коллизию в свой списочек коллизий. Если у тела не вызывается move_and_slide на каждом физическом кадре, то он никаких коллизий не увидит, хоть ты пятьдесят волков в него запусти на любой скорости. Если у тела нулевая скорость — он заметит коллизию в move_and_slide только если что-то встанет к нему вплотную или пересечется с ним. То же будет если он движется в направлении от волка или перпендикулярно движению волка. Тело не обязано знать, что в него кто-то там врезался, оно вообще может "не видеть" волка, даже если волк видит тело, если разрабу захотелось так настроить слои и маски.
Коллизия для конкретного тела — это конкретно ситуация "я пытаюсь сдвинуться на такой-то вектор, но если я так сдвинусь, мой хитбокс будет пересекаться с хитбоксом другого тела (которое я вижу через мою коллижн маску), поэтому мне приходится сдвинуться на какую-то другую величину". Все. Если тебе хочется обрабатывать бильярдные удары волком — как тебе уже написали, в налетающем объекте (ну и вообще во всех) делай типа
var collision_occured := move_and_slide()
if collision_occured:
____for i in get_slide_collision_count():
________var collider := get_slide_collision(i)
________if collider is MyCharacterBody:
____________collider.do_whatever_that_i_want_to_do_when_wolf_hits_this_body(...)
>I) A - стоит (может двигаться, но стоит по условию), в нём детектим (get_slide_collision_count) столкновение, он не отскакивает
>II) Б - двигается все время на A.
Так это абсолютно нормально, прочитай что написано в доках про get_slide_collision_count. Оно возвращает счет коллизий, возникших в последний вызов move_and_slide. move_and_slide пытается сдвинуть тело на скорость*дельта, если у него не получается, он записывает коллизию в свой списочек коллизий. Если у тела не вызывается move_and_slide на каждом физическом кадре, то он никаких коллизий не увидит, хоть ты пятьдесят волков в него запусти на любой скорости. Если у тела нулевая скорость — он заметит коллизию в move_and_slide только если что-то встанет к нему вплотную или пересечется с ним. То же будет если он движется в направлении от волка или перпендикулярно движению волка. Тело не обязано знать, что в него кто-то там врезался, оно вообще может "не видеть" волка, даже если волк видит тело, если разрабу захотелось так настроить слои и маски.
Коллизия для конкретного тела — это конкретно ситуация "я пытаюсь сдвинуться на такой-то вектор, но если я так сдвинусь, мой хитбокс будет пересекаться с хитбоксом другого тела (которое я вижу через мою коллижн маску), поэтому мне приходится сдвинуться на какую-то другую величину". Все. Если тебе хочется обрабатывать бильярдные удары волком — как тебе уже написали, в налетающем объекте (ну и вообще во всех) делай типа
var collision_occured := move_and_slide()
if collision_occured:
____for i in get_slide_collision_count():
________var collider := get_slide_collision(i)
________if collider is MyCharacterBody:
____________collider.do_whatever_that_i_want_to_do_when_wolf_hits_this_body(...)
>>102129
Там буквально ничего не говориться. Точнее говориться ровно то что ожидаешь. А ожидаешь получить все коллизии.
Ну мы как бы с коллайдерами работаем, что значит не обязательно, нафига мы его добавили (для столкновений, а значит и коллизии ловить).
Ты же видишь спокойно пропадают (если нет отскока). Сделай в демо круглые коллайдеры и будет 0 отскоков - будут исчезать все (если двигать не будешь).
В общем, там есть демо, ведёт себя эта шняга не интуитивно, информации настолько мало что даже ИИшка объяснить не может. Но судя по сорцам работает как объяснил анон (move_and_slide похер кроме себя, нет обмена, нет системы какой-то)
https://github.com/godotengine/godot/blob/63b7e027254e6b77b3d1036c89973060fb5be088/scene/2d/physics/character_body_2d.cpp#L45
Интереснее там _move_and_slide_floating с полем класса motion_results
Единственный вариант, не добавляя арен (Кто экономит на аренах? Лайк, подписка), это передавать ручками инфу между объектами, но надо учитывать момент, что иногда они будут касаться и детектить друг друга (безумие писать такое не на уровне сорцев движка).
В общем, годот как раскраска, многое нужно доделать самому.
>прочитай что написано в доках про get_slide_collision_count.
Там буквально ничего не говориться. Точнее говориться ровно то что ожидаешь. А ожидаешь получить все коллизии.
>Тело не обязано знать, что в него кто-то там врезался
Ну мы как бы с коллайдерами работаем, что значит не обязательно, нафига мы его добавили (для столкновений, а значит и коллизии ловить).
>Если у тела не вызывается move_and_slide на каждом физическом кадре, то он никаких коллизий не увидит, хоть ты пятьдесят волков в него запусти на любой скорости
Ты же видишь спокойно пропадают (если нет отскока). Сделай в демо круглые коллайдеры и будет 0 отскоков - будут исчезать все (если двигать не будешь).
В общем, там есть демо, ведёт себя эта шняга не интуитивно, информации настолько мало что даже ИИшка объяснить не может. Но судя по сорцам работает как объяснил анон (move_and_slide похер кроме себя, нет обмена, нет системы какой-то)
https://github.com/godotengine/godot/blob/63b7e027254e6b77b3d1036c89973060fb5be088/scene/2d/physics/character_body_2d.cpp#L45
Интереснее там _move_and_slide_floating с полем класса motion_results
Единственный вариант, не добавляя арен (Кто экономит на аренах? Лайк, подписка), это передавать ручками инфу между объектами, но надо учитывать момент, что иногда они будут касаться и детектить друг друга (безумие писать такое не на уровне сорцев движка).
В общем, годот как раскраска, многое нужно доделать самому.
>>102060
Детекти резкое изменение вектора или скорости постфактум. Хотя я для таких целей действительно Area с запасом использую
Детекти резкое изменение вектора или скорости постфактум. Хотя я для таких целей действительно Area с запасом использую
>>102167
Я не так прочел, но оказалось это еще хуже, в общем, это из серии - не будешь ничего в кадре вызывать - не будет и багов (ничего не будет).
>>Если у тела не вызывается move_and_slide на каждом физическом кадре, то он никаких коллизий не увидит, хоть ты пятьдесят волков в него запусти на любой скорости
Я не так прочел, но оказалось это еще хуже, в общем, это из серии - не будешь ничего в кадре вызывать - не будет и багов (ничего не будет).
>>102169
Я там не ищу решение, я воссоздаю проблему с коллизией (неочевидное поведение, плавающая ошибка, магическая ошибка).
Я там не ищу решение, я воссоздаю проблему с коллизией (неочевидное поведение, плавающая ошибка, магическая ошибка).
>>102082
Зачем в том коде столько бессмысленных "TODO"?
>>102084
Это сложнее правильно анимировать с физикой...
>>102167
Мне кажется, ты просто используешь инструмент не по прямому назначению. CharacterBody нужны для "персонажей", там буквально иконка человечка, а ты пытаешься реализовать пулю/снаряд/стрелу и т.п. Попадание в цель - это обычно код снаряда, а не пострадавшей от него цели, наподобие такого:
Дальше подгоняешь параметры, чтоб не пролетало.
>>102141
Только для 3D, с недавних пор. Мы обсуждаем 2D.
>>102129
Всё так.
>Там кода на 5-10 минут.
Зачем в том коде столько бессмысленных "TODO"?
>>102084
>мы как-будто смотрим на мир под углом
Это сложнее правильно анимировать с физикой...
>>102167
Мне кажется, ты просто используешь инструмент не по прямому назначению. CharacterBody нужны для "персонажей", там буквально иконка человечка, а ты пытаешься реализовать пулю/снаряд/стрелу и т.п. Попадание в цель - это обычно код снаряда, а не пострадавшей от него цели, наподобие такого:
>func _on_body_enters(body):
>_ if "take_damage" in body:
>_ _ body.take_damage(my_damage_value)
>_ spawn_explosion() # если это ракета
>_ queue_free() # самоуничтожение
Дальше подгоняешь параметры, чтоб не пролетало.
>>102141
>в годоте используется физика jolt
Только для 3D, с недавних пор. Мы обсуждаем 2D.
>>102129
Всё так.
>>102082
Судя по опыту других анонов с ИИ на Godot - эти "best practice" в кавычках неспроста... LLM может всякого галлюцинационировать и обернуть в убедительную обёртку, ещё и приправит приторной лестью. А ты и поверишь в это... Уж лучше самому по всем граблям пройтись и понять, что и как, чем верить многократно пережёванной информации из неизвестного и потому ненадёжного источника (на чём тренировали LLM? на большинстве сайтов в интернете тупо мусор сейчас).
>ИИ для обучения хорошо показывает "best practice"
Судя по опыту других анонов с ИИ на Godot - эти "best practice" в кавычках неспроста... LLM может всякого галлюцинационировать и обернуть в убедительную обёртку, ещё и приправит приторной лестью. А ты и поверишь в это... Уж лучше самому по всем граблям пройтись и понять, что и как, чем верить многократно пережёванной информации из неизвестного и потому ненадёжного источника (на чём тренировали LLM? на большинстве сайтов в интернете тупо мусор сейчас).
>>102230
Playground - это слепки (временные копии) от реальных проектов в начале своей жизни. Или почищенные копии.
А тодошки с маркером это для отката, чтобы потом почистить и протестировать что-то еще, не перечитывая весь код (через глобальный поиск). Playground может обрастать полезным кодом, поэтому откатить лучше чем потом в 100500 копиях искать нужный вариант.
Не надо додумывать и опять мне предлагать арену. Я возмущен тем что у меня два коллайдера и я не могу получить точно столкновение, это какой-то абсурд (сама проблема давно решена).
>Зачем в том коде столько бессмысленных "TODO"?
Playground - это слепки (временные копии) от реальных проектов в начале своей жизни. Или почищенные копии.
А тодошки с маркером это для отката, чтобы потом почистить и протестировать что-то еще, не перечитывая весь код (через глобальный поиск). Playground может обрастать полезным кодом, поэтому откатить лучше чем потом в 100500 копиях искать нужный вариант.
>Мне кажется, ты просто используешь инструмент не по прямому назначению.
Не надо додумывать и опять мне предлагать арену. Я возмущен тем что у меня два коллайдера и я не могу получить точно столкновение, это какой-то абсурд (сама проблема давно решена).
>>102234
Я полностью понимаю код и обычно спрашиваю какие-то мелкие вещи (особенно херотень с углами и синусами, которую я на память не помню/не знаю).
Собственно почему я докопался с коллизией, я хотел понять почему так работает.
У ИИшки еще удобно спрашивать "что тут происходит", она даже ASCII рисунки делает. А ты делал схематические рисунки для анонов?
Годот решения очень плохо гугляться. Часто ссылки приводят на какой-то узкоспецифичный вопрос с таким же узкоспефичным ответом.
Такое ощущение - хайп годота попал в эру ИИ и люди просто не спрашивают то что раньше бы спрашивали друг у друга, все ньюфажные вопросы исчезают в бездне ИИ я даже скучаю по stackoverflow
>Судя по опыту других анонов с ИИ на Godot - эти "best practice" в кавычках неспроста...
Я полностью понимаю код и обычно спрашиваю какие-то мелкие вещи (особенно херотень с углами и синусами, которую я на память не помню/не знаю).
Собственно почему я докопался с коллизией, я хотел понять почему так работает.
У ИИшки еще удобно спрашивать "что тут происходит", она даже ASCII рисунки делает. А ты делал схематические рисунки для анонов?
Годот решения очень плохо гугляться. Часто ссылки приводят на какой-то узкоспецифичный вопрос с таким же узкоспефичным ответом.
Такое ощущение - хайп годота попал в эру ИИ и люди просто не спрашивают то что раньше бы спрашивали друг у друга, все ньюфажные вопросы исчезают в бездне ИИ я даже скучаю по stackoverflow
>>102241
Рубрика Лайфхаки
Кто не понимает что за маркер и зачем он.
Чтобы найти точно все места через Ctrl+Shift+F
Такое еще использую чтобы связать несколько разных участков кода какой-то общей связью/информацией
# INFO: [2026-08-13--1647] Какой-то комментарий если надо
Теперь по [2026-08-13--1651] можно найти все места, при этом маркер всегда уникален (из-за даты и времени создания маркера)
>А тодошки с маркером
Рубрика Лайфхаки
Кто не понимает что за маркер и зачем он.
Чтобы найти точно все места через Ctrl+Shift+F
Такое еще использую чтобы связать несколько разных участков кода какой-то общей связью/информацией
# INFO: [2026-08-13--1647] Какой-то комментарий если надо
Теперь по [2026-08-13--1651] можно найти все места, при этом маркер всегда уникален (из-за даты и времени создания маркера)
>>102294
Ты про рендеринг 3D? Ну, попробуй "пикселизировать" (уменьшить разрешение). Щас это популярно.
>>102241
ИМХО, бред какой-то, никогда даже не думал сделать такое. Если мне нужно что-то там мелкое протестировать в Godot, я просто создаю новую сцену/скрипт/ресурс в папке res://test или типа того, где хранится всякий "мусор", который я планирую потом удалить или переписать начисто. Так как я не создаю лишних синглтонов (автозагрузочных сцен), любая новая сцена в моём проекте может запускаться независимо от всего остального проекта, т.е. у меня никогда не возникает необходимости делать "чистую" копию проекта...
Эм, а зачем "откатывать" полезный код? Если код полезный, ты его переносишь из res://test в res://game или в res://utils (для кода, который может пригодиться в нескольких разных проектах), или оформляешь как аддон в res://addons (для кода, который можно передать другим через гитхаб), что-то в этом духе. Откатывать не надо.
Сам себе создал проблемы (копии копий копий) и героически их преодолеваешь?
Во-первых, физика в играх - это по определению неточная штука, потому что ей нужно работать минимум 30 или даже 60 раз в секунду и оставлять время на графику, звук, логику и т.д. Точные столкновения возможны только в научных симуляциях, которым позволено "тормозить", потому что от них требуется не скорость как в играх, а точность результатов. Разве это не очевидно?..
Во-вторых, ты всё-таки можешь получить относительно точные столкновения двух коллайдеров, но ты должен хорошо понимать, что делает физический движок и чего он не делает. Сами по себе "коллайдеры" - это просто данные, описывающие какие-то части симуляции (фигуры в пространстве), а что с ними происходит - это уже другой вопрос. Если ты размещаешь коллайдеры в RigidBody, то они будут двигаться и реагировать на всё сами. Если ты размешаешь их в StaticBody, они ничего сами не делают, только мешают другим. А если в CharacterBody, то движок даёт что-то вроде StaticBody с дополнительным инструментом для "скользящего движения", но не более того - это называют "кинематическое движение" (в Godot 3 этот класс назывался KinematicBody), которое ставится в противовес "динамическому" (RigidBody). Использовать CharacterBody как "пассивный датчик столкновений" - это использование не по назначению, потому что он предназначен быть "кинематическим двигателем". Если ты этого не понимаешь, то виновато только твоё упрямство/стремление выдать желаемое за действительное.
"Area" переводится как "область" (площадь и т.п.), и подразумевает просто абстрактный участок пространства, который детектирует пересечения с другими участками пространства и также с физическими объектами в пространстве. "Арена" (arena) - это место, где кто-то с кем-то дерётся или сражается, типа боксёрского ринга. Не надо искажать слова, пиши "Area".
Ты про рендеринг 3D? Ну, попробуй "пикселизировать" (уменьшить разрешение). Щас это популярно.
>>102241
>слепки (временные копии) от реальных проектов в начале своей жизни
ИМХО, бред какой-то, никогда даже не думал сделать такое. Если мне нужно что-то там мелкое протестировать в Godot, я просто создаю новую сцену/скрипт/ресурс в папке res://test или типа того, где хранится всякий "мусор", который я планирую потом удалить или переписать начисто. Так как я не создаю лишних синглтонов (автозагрузочных сцен), любая новая сцена в моём проекте может запускаться независимо от всего остального проекта, т.е. у меня никогда не возникает необходимости делать "чистую" копию проекта...
>может обрастать полезным кодом, поэтому откатить лучше
Эм, а зачем "откатывать" полезный код? Если код полезный, ты его переносишь из res://test в res://game или в res://utils (для кода, который может пригодиться в нескольких разных проектах), или оформляешь как аддон в res://addons (для кода, который можно передать другим через гитхаб), что-то в этом духе. Откатывать не надо.
>...чем потом в 100500 копиях искать нужный вариант
Сам себе создал проблемы (копии копий копий) и героически их преодолеваешь?
>Я возмущен тем что у меня два коллайдера и я не могу получить точно столкновение
Во-первых, физика в играх - это по определению неточная штука, потому что ей нужно работать минимум 30 или даже 60 раз в секунду и оставлять время на графику, звук, логику и т.д. Точные столкновения возможны только в научных симуляциях, которым позволено "тормозить", потому что от них требуется не скорость как в играх, а точность результатов. Разве это не очевидно?..
Во-вторых, ты всё-таки можешь получить относительно точные столкновения двух коллайдеров, но ты должен хорошо понимать, что делает физический движок и чего он не делает. Сами по себе "коллайдеры" - это просто данные, описывающие какие-то части симуляции (фигуры в пространстве), а что с ними происходит - это уже другой вопрос. Если ты размещаешь коллайдеры в RigidBody, то они будут двигаться и реагировать на всё сами. Если ты размешаешь их в StaticBody, они ничего сами не делают, только мешают другим. А если в CharacterBody, то движок даёт что-то вроде StaticBody с дополнительным инструментом для "скользящего движения", но не более того - это называют "кинематическое движение" (в Godot 3 этот класс назывался KinematicBody), которое ставится в противовес "динамическому" (RigidBody). Использовать CharacterBody как "пассивный датчик столкновений" - это использование не по назначению, потому что он предназначен быть "кинематическим двигателем". Если ты этого не понимаешь, то виновато только твоё упрямство/стремление выдать желаемое за действительное.
>арену
"Area" переводится как "область" (площадь и т.п.), и подразумевает просто абстрактный участок пространства, который детектирует пересечения с другими участками пространства и также с физическими объектами в пространстве. "Арена" (arena) - это место, где кто-то с кем-то дерётся или сражается, типа боксёрского ринга. Не надо искажать слова, пиши "Area".
>>102294
Ты про рендеринг 3D? Ну, попробуй "пикселизировать" (уменьшить разрешение). Щас это популярно.
>>102241
ИМХО, бред какой-то, никогда даже не думал сделать такое. Если мне нужно что-то там мелкое протестировать в Godot, я просто создаю новую сцену/скрипт/ресурс в папке res://test или типа того, где хранится всякий "мусор", который я планирую потом удалить или переписать начисто. Так как я не создаю лишних синглтонов (автозагрузочных сцен), любая новая сцена в моём проекте может запускаться независимо от всего остального проекта, т.е. у меня никогда не возникает необходимости делать "чистую" копию проекта...
Эм, а зачем "откатывать" полезный код? Если код полезный, ты его переносишь из res://test в res://game или в res://utils (для кода, который может пригодиться в нескольких разных проектах), или оформляешь как аддон в res://addons (для кода, который можно передать другим через гитхаб), что-то в этом духе. Откатывать не надо.
Сам себе создал проблемы (копии копий копий) и героически их преодолеваешь?
Во-первых, физика в играх - это по определению неточная штука, потому что ей нужно работать минимум 30 или даже 60 раз в секунду и оставлять время на графику, звук, логику и т.д. Точные столкновения возможны только в научных симуляциях, которым позволено "тормозить", потому что от них требуется не скорость как в играх, а точность результатов. Разве это не очевидно?..
Во-вторых, ты всё-таки можешь получить относительно точные столкновения двух коллайдеров, но ты должен хорошо понимать, что делает физический движок и чего он не делает. Сами по себе "коллайдеры" - это просто данные, описывающие какие-то части симуляции (фигуры в пространстве), а что с ними происходит - это уже другой вопрос. Если ты размещаешь коллайдеры в RigidBody, то они будут двигаться и реагировать на всё сами. Если ты размешаешь их в StaticBody, они ничего сами не делают, только мешают другим. А если в CharacterBody, то движок даёт что-то вроде StaticBody с дополнительным инструментом для "скользящего движения", но не более того - это называют "кинематическое движение" (в Godot 3 этот класс назывался KinematicBody), которое ставится в противовес "динамическому" (RigidBody). Использовать CharacterBody как "пассивный датчик столкновений" - это использование не по назначению, потому что он предназначен быть "кинематическим двигателем". Если ты этого не понимаешь, то виновато только твоё упрямство/стремление выдать желаемое за действительное.
"Area" переводится как "область" (площадь и т.п.), и подразумевает просто абстрактный участок пространства, который детектирует пересечения с другими участками пространства и также с физическими объектами в пространстве. "Арена" (arena) - это место, где кто-то с кем-то дерётся или сражается, типа боксёрского ринга. Не надо искажать слова, пиши "Area".
Ты про рендеринг 3D? Ну, попробуй "пикселизировать" (уменьшить разрешение). Щас это популярно.
>>102241
>слепки (временные копии) от реальных проектов в начале своей жизни
ИМХО, бред какой-то, никогда даже не думал сделать такое. Если мне нужно что-то там мелкое протестировать в Godot, я просто создаю новую сцену/скрипт/ресурс в папке res://test или типа того, где хранится всякий "мусор", который я планирую потом удалить или переписать начисто. Так как я не создаю лишних синглтонов (автозагрузочных сцен), любая новая сцена в моём проекте может запускаться независимо от всего остального проекта, т.е. у меня никогда не возникает необходимости делать "чистую" копию проекта...
>может обрастать полезным кодом, поэтому откатить лучше
Эм, а зачем "откатывать" полезный код? Если код полезный, ты его переносишь из res://test в res://game или в res://utils (для кода, который может пригодиться в нескольких разных проектах), или оформляешь как аддон в res://addons (для кода, который можно передать другим через гитхаб), что-то в этом духе. Откатывать не надо.
>...чем потом в 100500 копиях искать нужный вариант
Сам себе создал проблемы (копии копий копий) и героически их преодолеваешь?
>Я возмущен тем что у меня два коллайдера и я не могу получить точно столкновение
Во-первых, физика в играх - это по определению неточная штука, потому что ей нужно работать минимум 30 или даже 60 раз в секунду и оставлять время на графику, звук, логику и т.д. Точные столкновения возможны только в научных симуляциях, которым позволено "тормозить", потому что от них требуется не скорость как в играх, а точность результатов. Разве это не очевидно?..
Во-вторых, ты всё-таки можешь получить относительно точные столкновения двух коллайдеров, но ты должен хорошо понимать, что делает физический движок и чего он не делает. Сами по себе "коллайдеры" - это просто данные, описывающие какие-то части симуляции (фигуры в пространстве), а что с ними происходит - это уже другой вопрос. Если ты размещаешь коллайдеры в RigidBody, то они будут двигаться и реагировать на всё сами. Если ты размешаешь их в StaticBody, они ничего сами не делают, только мешают другим. А если в CharacterBody, то движок даёт что-то вроде StaticBody с дополнительным инструментом для "скользящего движения", но не более того - это называют "кинематическое движение" (в Godot 3 этот класс назывался KinematicBody), которое ставится в противовес "динамическому" (RigidBody). Использовать CharacterBody как "пассивный датчик столкновений" - это использование не по назначению, потому что он предназначен быть "кинематическим двигателем". Если ты этого не понимаешь, то виновато только твоё упрямство/стремление выдать желаемое за действительное.
>арену
"Area" переводится как "область" (площадь и т.п.), и подразумевает просто абстрактный участок пространства, который детектирует пересечения с другими участками пространства и также с физическими объектами в пространстве. "Арена" (arena) - это место, где кто-то с кем-то дерётся или сражается, типа боксёрского ринга. Не надо искажать слова, пиши "Area".
>>102328
Ну так тебе все равно придется копии делать, ты не хочешь в игровые скрипты гадить. Проще даже в моменте проект скопировать - и нагадить там.
Тест сцены для проверки механики я тоже делают, но они в рамках игровой логики, а не тотального дебага с 100500 временными изменениями под тест.
Это был тонкий тролинг продолжая тему волков в цирке - ну типа арена - цирк, волки - ну вы поняли, смешно же, че не смеешься? А потом я правда затупил под усталость. Вот только нафига ты высираешь целую пасту на всякую фигню? Мог бы кратко стебануться. Лучше бы по движку так писал.
Как для CharacterBody без Area?
Еще раз, в той ситуации физика работает нормально, там все взаимодействуйте с коллизией. Проблема начинается только в отскоке, который регистрируется только у одно стороны (что уже по логике факап).
Коллайдеры тоже не бесплатная штука, чтобы им разбрасываться, да и хочется получить точку столкновения и нормаль.
В общем, опасная фигня, несущая в себе очень трудновоспроизводимую ошибку, если отскоки в игре у тебя редки (относительно малые скорости движения).
Это говнокод. Вместо глобальной системы или просто передачи сообщений между объектами (это, кстати, сложнее, но движок знает порядок вызовов), там тупо поле класса (хотя это поле public).
Vector<PS2DT::MotionResult> motion_results;
Но да, поделать нечего, нужно только смериться, понять и простить. Таков путь.
Когда-нибудь я напишу свою физику для 2D с блэкджеком и волками. Но не сегодня.
>res://test
Ну так тебе все равно придется копии делать, ты не хочешь в игровые скрипты гадить. Проще даже в моменте проект скопировать - и нагадить там.
Тест сцены для проверки механики я тоже делают, но они в рамках игровой логики, а не тотального дебага с 100500 временными изменениями под тест.
>>арену
Это был тонкий тролинг продолжая тему волков в цирке - ну типа арена - цирк, волки - ну вы поняли, смешно же, че не смеешься? А потом я правда затупил под усталость. Вот только нафига ты высираешь целую пасту на всякую фигню? Мог бы кратко стебануться. Лучше бы по движку так писал.
>Во-вторых, ты всё-таки можешь получить относительно точные столкновения двух коллайдеров
Как для CharacterBody без Area?
>Во-первых, физика в играх - это по определению неточная штука
Еще раз, в той ситуации физика работает нормально, там все взаимодействуйте с коллизией. Проблема начинается только в отскоке, который регистрируется только у одно стороны (что уже по логике факап).
Коллайдеры тоже не бесплатная штука, чтобы им разбрасываться, да и хочется получить точку столкновения и нормаль.
В общем, опасная фигня, несущая в себе очень трудновоспроизводимую ошибку, если отскоки в игре у тебя редки (относительно малые скорости движения).
>Если ты этого не понимаешь, то виновато только твоё упрямство/стремление выдать желаемое за действительное.
Это говнокод. Вместо глобальной системы или просто передачи сообщений между объектами (это, кстати, сложнее, но движок знает порядок вызовов), там тупо поле класса (хотя это поле public).
Vector<PS2DT::MotionResult> motion_results;
Но да, поделать нечего, нужно только смериться, понять и простить. Таков путь.
Когда-нибудь я напишу свою физику для 2D с блэкджеком и волками. Но не сегодня.
>>102373
Он вероятностно подбирает в зависимости от контекста, причем иногда не только словами, а слогами или даже буквой за буквой. Понимая как работает эта хрень, в жизнь не доверишь ему код.
Мне один раз высрал правильный код, но написал оператор "+=" вместо "=" просто потому что где-то токен += был чуть выше, а не потому что он "знал".
Было бы круто если бы он реально знал/понимал без вероятностей.
>Но если ИИ знает ответ на вопрос, значит он его где-то прочитал...
Он вероятностно подбирает в зависимости от контекста, причем иногда не только словами, а слогами или даже буквой за буквой. Понимая как работает эта хрень, в жизнь не доверишь ему код.
Мне один раз высрал правильный код, но написал оператор "+=" вместо "=" просто потому что где-то токен += был чуть выше, а не потому что он "знал".
Было бы круто если бы он реально знал/понимал без вероятностей.
>>102328
Кстати, почему тогда CharacterBody отскакивает от CharacterBody?
В теории, если отключить отскок это бы полностью нивелировало проблему.
> А если в CharacterBody, то движок даёт что-то вроде StaticBody с дополнительным инструментом для "скользящего движения", но не более того - это называют "кинематическое движение"
Кстати, почему тогда CharacterBody отскакивает от CharacterBody?
В теории, если отключить отскок это бы полностью нивелировало проблему.
402 Кб, mp4,982x570, 0:27
Ппц я пошел помусолил с ИИшкой и знаете в чем была проблема? В той самом операторе "+="
velocity += direction * speed
Нет никакого отскока и рикошета!!! ВНИМАНИЕ! Это я сам создаю рикошет!!!
Вы понимаете что ИИ стала умнее двачеров? Умнее меня, тебя и меня!!! ЭТО ВСЕ, ПОЧАНЫ, ЭТО СИНГУЛЯРИТИ!!!
velocity += direction * speed
Нет никакого отскока и рикошета!!! ВНИМАНИЕ! Это я сам создаю рикошет!!!
Вы понимаете что ИИ стала умнее двачеров? Умнее меня, тебя и меня!!! ЭТО ВСЕ, ПОЧАНЫ, ЭТО СИНГУЛЯРИТИ!!!
>>102388
Я... ЧЕЛОВЕК... РИКОШЕТ!
Все, теперь это мое погоняло в чатике.
Живите с этим
>Это я сам создаю рикошет!!!
Я... ЧЕЛОВЕК... РИКОШЕТ!
Все, теперь это мое погоняло в чатике.
Живите с этим
>>102440
Было б что отрицать... Ну может нейронка слепить веб-игру для слабоумных младенцев в Яндекс.Слоп и принести три копейки из-за того, что игру удалят за неактивность (а хочешь активность - плати, норм развод). А если я хочу ГТА? И не на кубиках, а нормально. Как бесплатная из числа ещё доступных нейронка мне поможет? Или опять платить за кота в мешке, который может помочь, а может и навредить? Мы в СНГ живём и покупаем всё что нужно для домашнего и рабочего компьютера на торрент-трекерах, а последние годы снаружи нам активно запрещают покупать (хотя мы и не собирались). И ты НАМ предлагаешь платить за токены для слот-машины в казино? Лол...
Или ты так радуешься за барина с триллионами долларов капитала, у которого суперкомпьютер в личном пользовании?
>отрицание
Было б что отрицать... Ну может нейронка слепить веб-игру для слабоумных младенцев в Яндекс.Слоп и принести три копейки из-за того, что игру удалят за неактивность (а хочешь активность - плати, норм развод). А если я хочу ГТА? И не на кубиках, а нормально. Как бесплатная из числа ещё доступных нейронка мне поможет? Или опять платить за кота в мешке, который может помочь, а может и навредить? Мы в СНГ живём и покупаем всё что нужно для домашнего и рабочего компьютера на торрент-трекерах, а последние годы снаружи нам активно запрещают покупать (хотя мы и не собирались). И ты НАМ предлагаешь платить за токены для слот-машины в казино? Лол...
Или ты так радуешься за барина с триллионами долларов капитала, у которого суперкомпьютер в личном пользовании?
Спасибо за демонстрацию. Наглядно.
Сап, аноны, мне посоветовали годот здесь >>1101885 →, в целом мне понятно после чтения манов, но как в годоте-4 загрузить картинку железно в линейном цвете вместо sRGB - так и не понял (юзаю ч/б картинку как карту высот для расчетов во фрагментном шейдере). Вроде бы при выборе вулкана шейдер всегда работает в линейном цвете, но у меня загружается криво. Если грузить с source_color в sampler2D - становится лучше, а по ману должно быть наоборот.
>>102574
Потом появляется такая игра как римволд-в-фактории и все эти высказывания рушатся, потому что 90% там это код и безудержная отладка механик.
Игры разные.
>Мы всё ещё понимаем, что игра это на 90% арт, сторителлинг, геймплей.
Потом появляется такая игра как римволд-в-фактории и все эти высказывания рушатся, потому что 90% там это код и безудержная отладка механик.
Игры разные.
1,3 Мб, 1920x1080Submissions open for Godot 2026 showreel
https://godotengine.org/article/submissions-open-godot-2026-showreel/
Отправляй, слышь
https://godotengine.org/article/submissions-open-godot-2026-showreel/
Отправляй, слышь
>>102634
В любой непонятной ситуации с языком шейдеров - конвертируй StandardMaterial3D в ShaderMaterial:
У тебя такая строчка какой-то неправильный результат создаёт?
В каком формате данные в картинке? Я погуглил - данные могут быть по-разному закодированы. Если твой редактор графики закодировал данные в другом формате, Godot может неправильно их интерпретировать. Попробуй взять эту картинку и переэкспортировать с другими настройками экспорта/пересохранить через другой редактор картинок. Подробнее подсказать не могу, т.к. сам не разбираюсь в этих "color space" - нафиг их вообще придумали, непонятно...
>>1101862 →
Если ты хочешь рендерить на CPU сложную динамичную 3D сцену в реальном времени (60 fps) - да, тогда тебе нужен компилируемый язык и вдобавок куча всяких оптимизаций для твоих алгоритмов работы с графикой, иначе не взлетит. Если тебе достаточно сгенерировать одну картинку за сколько угодно времени - язык тут вообще не важен.
>>1102028 →
По моему опыту, если ты в функции _draw() пишешь простой код для рисования 2D элементов GUI - в большинстве случаев ты даже не заметишь работу своего кода, это будет мгновенно (результат как-то кэшируется и его можно обновить запросом queue_redraw, но даже в реальном времени норм). Также ты можешь генерировать пикселями в Image, но разумное разрешение будет где-то до 256x256 (если в один поток). Всё во многом зависит от того, что ты хочешь сделать - если тебе достаточно шум Перлина налепить, то это будет быстро и для бОльших разрешений (ибо ты просто обращаешься к API движка, который всё на C++ делает), а если ты напишешь вручную что-то вроде нейросетки с сотней нейронов на пиксель - то разрешение, рациональное для реального времени (скажем, 30 кадров в секунду), на процессоре на GDScript, будет намного меньше, и такое будет лучше переписать на шейдеры или на C++. Рекомендую для начала сделать прототип на GDScript, а уже потом переписывать на что-то другое, если результат выглядит норм (кроме шейдерных эффектов, разумеется - их проще сразу в шейдере написать, чем делать for x in size: for y in size:).
>юзаю ч/б картинку как карту высот для расчетов
В любой непонятной ситуации с языком шейдеров - конвертируй StandardMaterial3D в ShaderMaterial:
>uniform sampler2D texture_heightmap : hint_default_black, filter_linear_mipmap, repeat_enable;
У тебя такая строчка какой-то неправильный результат создаёт?
>у меня загружается криво
В каком формате данные в картинке? Я погуглил - данные могут быть по-разному закодированы. Если твой редактор графики закодировал данные в другом формате, Godot может неправильно их интерпретировать. Попробуй взять эту картинку и переэкспортировать с другими настройками экспорта/пересохранить через другой редактор картинок. Подробнее подсказать не могу, т.к. сам не разбираюсь в этих "color space" - нафиг их вообще придумали, непонятно...
>>1101862 →
>Я правильно понял что для рендеринга на процессоре нужно что-то с кодингом на си или плюсах для скорости
Если ты хочешь рендерить на CPU сложную динамичную 3D сцену в реальном времени (60 fps) - да, тогда тебе нужен компилируемый язык и вдобавок куча всяких оптимизаций для твоих алгоритмов работы с графикой, иначе не взлетит. Если тебе достаточно сгенерировать одну картинку за сколько угодно времени - язык тут вообще не важен.
>>1102028 →
>Годот мне понравился, а как там с вычислениями на проце, не будет медленно из-за недопитона?
По моему опыту, если ты в функции _draw() пишешь простой код для рисования 2D элементов GUI - в большинстве случаев ты даже не заметишь работу своего кода, это будет мгновенно (результат как-то кэшируется и его можно обновить запросом queue_redraw, но даже в реальном времени норм). Также ты можешь генерировать пикселями в Image, но разумное разрешение будет где-то до 256x256 (если в один поток). Всё во многом зависит от того, что ты хочешь сделать - если тебе достаточно шум Перлина налепить, то это будет быстро и для бОльших разрешений (ибо ты просто обращаешься к API движка, который всё на C++ делает), а если ты напишешь вручную что-то вроде нейросетки с сотней нейронов на пиксель - то разрешение, рациональное для реального времени (скажем, 30 кадров в секунду), на процессоре на GDScript, будет намного меньше, и такое будет лучше переписать на шейдеры или на C++. Рекомендую для начала сделать прототип на GDScript, а уже потом переписывать на что-то другое, если результат выглядит норм (кроме шейдерных эффектов, разумеется - их проще сразу в шейдере написать, чем делать for x in size: for y in size:).
>>102634
В любой непонятной ситуации с языком шейдеров - конвертируй StandardMaterial3D в ShaderMaterial:
У тебя такая строчка какой-то неправильный результат создаёт?
В каком формате данные в картинке? Я погуглил - данные могут быть по-разному закодированы. Если твой редактор графики закодировал данные в другом формате, Godot может неправильно их интерпретировать. Попробуй взять эту картинку и переэкспортировать с другими настройками экспорта/пересохранить через другой редактор картинок. Подробнее подсказать не могу, т.к. сам не разбираюсь в этих "color space" - нафиг их вообще придумали, непонятно...
>>1101862 →
Если ты хочешь рендерить на CPU сложную динамичную 3D сцену в реальном времени (60 fps) - да, тогда тебе нужен компилируемый язык и вдобавок куча всяких оптимизаций для твоих алгоритмов работы с графикой, иначе не взлетит. Если тебе достаточно сгенерировать одну картинку за сколько угодно времени - язык тут вообще не важен.
>>1102028 →
По моему опыту, если ты в функции _draw() пишешь простой код для рисования 2D элементов GUI - в большинстве случаев ты даже не заметишь работу своего кода, это будет мгновенно (результат как-то кэшируется и его можно обновить запросом queue_redraw, но даже в реальном времени норм). Также ты можешь генерировать пикселями в Image, но разумное разрешение будет где-то до 256x256 (если в один поток). Всё во многом зависит от того, что ты хочешь сделать - если тебе достаточно шум Перлина налепить, то это будет быстро и для бОльших разрешений (ибо ты просто обращаешься к API движка, который всё на C++ делает), а если ты напишешь вручную что-то вроде нейросетки с сотней нейронов на пиксель - то разрешение, рациональное для реального времени (скажем, 30 кадров в секунду), на процессоре на GDScript, будет намного меньше, и такое будет лучше переписать на шейдеры или на C++. Рекомендую для начала сделать прототип на GDScript, а уже потом переписывать на что-то другое, если результат выглядит норм (кроме шейдерных эффектов, разумеется - их проще сразу в шейдере написать, чем делать for x in size: for y in size:).
>юзаю ч/б картинку как карту высот для расчетов
В любой непонятной ситуации с языком шейдеров - конвертируй StandardMaterial3D в ShaderMaterial:
>uniform sampler2D texture_heightmap : hint_default_black, filter_linear_mipmap, repeat_enable;
У тебя такая строчка какой-то неправильный результат создаёт?
>у меня загружается криво
В каком формате данные в картинке? Я погуглил - данные могут быть по-разному закодированы. Если твой редактор графики закодировал данные в другом формате, Godot может неправильно их интерпретировать. Попробуй взять эту картинку и переэкспортировать с другими настройками экспорта/пересохранить через другой редактор картинок. Подробнее подсказать не могу, т.к. сам не разбираюсь в этих "color space" - нафиг их вообще придумали, непонятно...
>>1101862 →
>Я правильно понял что для рендеринга на процессоре нужно что-то с кодингом на си или плюсах для скорости
Если ты хочешь рендерить на CPU сложную динамичную 3D сцену в реальном времени (60 fps) - да, тогда тебе нужен компилируемый язык и вдобавок куча всяких оптимизаций для твоих алгоритмов работы с графикой, иначе не взлетит. Если тебе достаточно сгенерировать одну картинку за сколько угодно времени - язык тут вообще не важен.
>>1102028 →
>Годот мне понравился, а как там с вычислениями на проце, не будет медленно из-за недопитона?
По моему опыту, если ты в функции _draw() пишешь простой код для рисования 2D элементов GUI - в большинстве случаев ты даже не заметишь работу своего кода, это будет мгновенно (результат как-то кэшируется и его можно обновить запросом queue_redraw, но даже в реальном времени норм). Также ты можешь генерировать пикселями в Image, но разумное разрешение будет где-то до 256x256 (если в один поток). Всё во многом зависит от того, что ты хочешь сделать - если тебе достаточно шум Перлина налепить, то это будет быстро и для бОльших разрешений (ибо ты просто обращаешься к API движка, который всё на C++ делает), а если ты напишешь вручную что-то вроде нейросетки с сотней нейронов на пиксель - то разрешение, рациональное для реального времени (скажем, 30 кадров в секунду), на процессоре на GDScript, будет намного меньше, и такое будет лучше переписать на шейдеры или на C++. Рекомендую для начала сделать прототип на GDScript, а уже потом переписывать на что-то другое, если результат выглядит норм (кроме шейдерных эффектов, разумеется - их проще сразу в шейдере написать, чем делать for x in size: for y in size:).
>>102788
Спасибо за подсказку, анон, походу сама пнгшка с картой высот была кривая (рипнута из игры). Нарисовал просто линейный градиент, все сошлось с маном - без source_color ровно, с ним - криво.
>>102788
На проце только всякие древние алгоритмы, которые плохо распараллеливаются для шейдеров (о которых в той древности и не думали), скорее всего скорость современных процов компенсирует слоупочность недопитона. Может еще придумаю как сделать генерацию кадров на шейдерах, если недопитон таки не вытянет.
Спасибо за подсказку, анон, походу сама пнгшка с картой высот была кривая (рипнута из игры). Нарисовал просто линейный градиент, все сошлось с маном - без source_color ровно, с ним - криво.
>>102788
>Если ты хочешь рендерить на CPU сложную динамичную 3D сцену в реальном времени (60 fps)
На проце только всякие древние алгоритмы, которые плохо распараллеливаются для шейдеров (о которых в той древности и не думали), скорее всего скорость современных процов компенсирует слоупочность недопитона. Может еще придумаю как сделать генерацию кадров на шейдерах, если недопитон таки не вытянет.
>>100297
>>100574
Ладно, вот тебе боёвка... Пока что это грубый прототип, нужно будет отрефакторить его полностью.
Если непонятно по видео - урон у всех героев фиксированный (-15 здоровья), но даётся бонус или штраф за разницу высоты между атакующим и защищающимся. Поэтому в данный момент оптимальная тактика одна - забраться повыше и заманить врага на клетку пониже, получая бонус до x2 от базового урона. Чтобы было больше интересных тактик, придётся добавлять многие другие способности для различных героев.
По моей задумке, во время применения навыка (которое сейчас мгновенное) на экране должны появляться полноразмерные (не чиби) 2D спрайты героев игрока (которые применяют навык) и противника (на которых подействует навык), слегка анимироваться (всего 2-3 кадра или Live2D анимация), и исчезать с экрана. Т.е. фигурки с чибиками показывают положение в пространстве, а изображение навыков происходит в 2D.
Также по задумке, можно будет перемещать надгробия и воскрешать героев, поэтому они не исчезают. Основной задачей игрока является "найти и забрать новых героев и/или лут, не потеряв при этом уже имеющихся героев", при этом, погибшего героя можно забросить в портал и вернуть к жизни после того, как миссия будет завершена... Возможно даже пожертвовать кем-то, чтобы спасти более ценного героя.
>в игре с боевкой первое что нужно делать эту саму боевку
>>100574
>Но все равно ты не то делаешь. Сделай сначала боевку
Ладно, вот тебе боёвка... Пока что это грубый прототип, нужно будет отрефакторить его полностью.
Если непонятно по видео - урон у всех героев фиксированный (-15 здоровья), но даётся бонус или штраф за разницу высоты между атакующим и защищающимся. Поэтому в данный момент оптимальная тактика одна - забраться повыше и заманить врага на клетку пониже, получая бонус до x2 от базового урона. Чтобы было больше интересных тактик, придётся добавлять многие другие способности для различных героев.
По моей задумке, во время применения навыка (которое сейчас мгновенное) на экране должны появляться полноразмерные (не чиби) 2D спрайты героев игрока (которые применяют навык) и противника (на которых подействует навык), слегка анимироваться (всего 2-3 кадра или Live2D анимация), и исчезать с экрана. Т.е. фигурки с чибиками показывают положение в пространстве, а изображение навыков происходит в 2D.
Также по задумке, можно будет перемещать надгробия и воскрешать героев, поэтому они не исчезают. Основной задачей игрока является "найти и забрать новых героев и/или лут, не потеряв при этом уже имеющихся героев", при этом, погибшего героя можно забросить в портал и вернуть к жизни после того, как миссия будет завершена... Возможно даже пожертвовать кем-то, чтобы спасти более ценного героя.
>>102837
Важно понимать GDScript это не питон, они похоже только синтаксически (визуально), дальше сходство заканчивается. Он никаким образом не собирает недостатки интерпретатора питона, это два разных мира.
Godot shader language - это вообще другое, это даже не GDScript.
Суть обычно простая, если ты не знаешь как устроен и работает GDScript и GDShader - то думать об оптимизации тебе еще очень рано. Так что никакой "недо-питон" тебе там ничего не испортит, если сам не испортишь.
Без агрессии, но понизь планочку. Годот достаточно гибкий для многих извращений, плюс у тебя есть сорцы. Так что грызи этот камень без импульсивный выпадов типа "недо-питон", "вытянет", "слоупочность".
Просто с пассивной агрессией тебя быстро пошлют нахер, а технически грамотных анонов тут полторы штуки (и все они психически стабильны как последние элементы таблицы Менделеева) - так что держишь за них.
Добро пожаловать в комьюнити :)
>Может еще придумаю как сделать генерацию кадров на шейдерах, если недопитон таки не вытянет.
Важно понимать GDScript это не питон, они похоже только синтаксически (визуально), дальше сходство заканчивается. Он никаким образом не собирает недостатки интерпретатора питона, это два разных мира.
Godot shader language - это вообще другое, это даже не GDScript.
Суть обычно простая, если ты не знаешь как устроен и работает GDScript и GDShader - то думать об оптимизации тебе еще очень рано. Так что никакой "недо-питон" тебе там ничего не испортит, если сам не испортишь.
Без агрессии, но понизь планочку. Годот достаточно гибкий для многих извращений, плюс у тебя есть сорцы. Так что грызи этот камень без импульсивный выпадов типа "недо-питон", "вытянет", "слоупочность".
Просто с пассивной агрессией тебя быстро пошлют нахер, а технически грамотных анонов тут полторы штуки (и все они психически стабильны как последние элементы таблицы Менделеева) - так что держишь за них.
Добро пожаловать в комьюнити :)
>>102845
О, ты выжил после болезни, поздравляю.
Сделай хотя бы легкий выпад во время удара (юнита на юнит). Делается он быстро, зато сильный фидбек по восприятию от боя.
Ну или что-то свое, не хватает фидбека по восприятию, цифорок мало (да, я прочитал что ты хочешь сделать отдельный экран)
Вот, поэтому я и говорю что надо делать первую очередь важный геймплей или боевку. Есть подозрения что этот экран может раздражающе "мигать" и бить по мозгам/глазам, поэтому надо сразу протестить, это может изменить половину боевки и геймплея.
>Ладно, вот тебе боёвка...
О, ты выжил после болезни, поздравляю.
Сделай хотя бы легкий выпад во время удара (юнита на юнит). Делается он быстро, зато сильный фидбек по восприятию от боя.
Ну или что-то свое, не хватает фидбека по восприятию, цифорок мало (да, я прочитал что ты хочешь сделать отдельный экран)
>По моей задумке, во время применения навыка (которое сейчас мгновенное) на экране должны появляться полноразмерные (не чиби) 2D спрайты героев игрока (которые применяют навык) и противника (на которых подействует навык), слегка анимироваться (всего 2-3 кадра или Live2D анимация), и исчезать с экрана. Т.е. фигурки с чибиками показывают положение в пространстве, а изображение навыков происходит в 2D.
Вот, поэтому я и говорю что надо делать первую очередь важный геймплей или боевку. Есть подозрения что этот экран может раздражающе "мигать" и бить по мозгам/глазам, поэтому надо сразу протестить, это может изменить половину боевки и геймплея.
>>102845
С учебы не видел блок-схем. На самом деле тугая и неудобная штука, умерло так же как умерло UML.
Мы обычно разрабатываем снизу вверх, попробуй набросать логику сверху вниз. Создать все классы/объекты, прописать взаимодействия между ними (забивая методы pass, а лучше как в котлине сделать функцию TODO() которая бросает исключение если забыл имплементировать). А уже потом заполняй реальным кодом.
То есть, ты как бы оперируешь взаимодействием на уровне объектов и из методов, а реализацию оставляешь на потом.
Ты опытный кодер, поймешь что это читается и проектируется проще и быстрее.
>пик2
С учебы не видел блок-схем. На самом деле тугая и неудобная штука, умерло так же как умерло UML.
Мы обычно разрабатываем снизу вверх, попробуй набросать логику сверху вниз. Создать все классы/объекты, прописать взаимодействия между ними (забивая методы pass, а лучше как в котлине сделать функцию TODO() которая бросает исключение если забыл имплементировать). А уже потом заполняй реальным кодом.
То есть, ты как бы оперируешь взаимодействием на уровне объектов и из методов, а реализацию оставляешь на потом.
Ты опытный кодер, поймешь что это читается и проектируется проще и быстрее.
>>102848
>>102845
Ну наверное что-то такое:
GameManager.newRound()
GameManager.loadRound()
GameManager.saveRound()
GameManager.startRound()
RoundManager().searchTarget()
RoundManager().chooseTeam()
RoundManager().chooseBadUnit()
RoundManager().activationGate()
RoundManager().restoreCamera()
RoundManager().nextRound()
TacticalСombat.chooseUnit()
TacticalСombat.moveUnitTo()
TacticalСombat.serachUnit()
TacticalСombat.serachLoot()
TacticalСombat.collectLoot()
TacticalСombat.nextRound(currentRoundManager)
TacticalСombat.atack(currentAtackManager)
TacticalСombat.isTimeUp()
TacticalСombat.getAllUnit() > 0
Тут пока я набросал, уже стало видно какие взаимодействия надо поменять и что некоторые объекты надо поделить еще (слишком много на себя берут, не по роли). Но ты уже сам разберешься. В любом случае проектировать весело, ты буквально думаешь, "о мне нужно тут проверить кончилось ли время - значит мне нужен метод/свойство isTimeUp()". Ты уже мыслишь абстракцией выше - ты не думаешь как ты это сделаешь, ты просто говоришь - тут нужно это и потом это сделаешь.
Это и есть проектирование сверху вниз. Сначала абстракции/взаимодействие - потом код
>>102845
Ну наверное что-то такое:
GameManager.newRound()
GameManager.loadRound()
GameManager.saveRound()
GameManager.startRound()
RoundManager().searchTarget()
RoundManager().chooseTeam()
RoundManager().chooseBadUnit()
RoundManager().activationGate()
RoundManager().restoreCamera()
RoundManager().nextRound()
TacticalСombat.chooseUnit()
TacticalСombat.moveUnitTo()
TacticalСombat.serachUnit()
TacticalСombat.serachLoot()
TacticalСombat.collectLoot()
TacticalСombat.nextRound(currentRoundManager)
TacticalСombat.atack(currentAtackManager)
TacticalСombat.isTimeUp()
TacticalСombat.getAllUnit() > 0
Тут пока я набросал, уже стало видно какие взаимодействия надо поменять и что некоторые объекты надо поделить еще (слишком много на себя берут, не по роли). Но ты уже сам разберешься. В любом случае проектировать весело, ты буквально думаешь, "о мне нужно тут проверить кончилось ли время - значит мне нужен метод/свойство isTimeUp()". Ты уже мыслишь абстракцией выше - ты не думаешь как ты это сделаешь, ты просто говоришь - тут нужно это и потом это сделаешь.
Это и есть проектирование сверху вниз. Сначала абстракции/взаимодействие - потом код
>>102848
>>102845
Ну наверное что-то такое:
GameManager.newRound()
GameManager.loadRound()
GameManager.saveRound()
GameManager.startRound()
RoundManager().searchTarget()
RoundManager().chooseTeam()
RoundManager().chooseBadUnit()
RoundManager().activationGate()
RoundManager().restoreCamera()
RoundManager().nextRound()
TacticalСombat.chooseUnit()
TacticalСombat.moveUnitTo()
TacticalСombat.serachUnit()
TacticalСombat.serachLoot()
TacticalСombat.collectLoot()
TacticalСombat.nextRound(currentRoundManager)
TacticalСombat.atack(currentAtackManager)
TacticalСombat.isTimeUp()
TacticalСombat.getAllUnit() > 0
Тут пока я набросал, уже стало видно какие взаимодействия надо поменять и что некоторые объекты надо поделить еще (слишком много на себя берут, не по роли). Но ты уже сам разберешься. В любом случае проектировать весело, ты буквально думаешь, "о мне нужно тут проверить кончилось ли время - значит мне нужен метод/свойство isTimeUp()". Ты уже мыслишь абстракцией выше - ты не думаешь как ты это сделаешь, ты просто говоришь - тут нужно это и потом это сделаешь.
Это и есть проектирование сверху вниз. Сначала абстракции/взаимодействие - потом код
>>102845
Ну наверное что-то такое:
GameManager.newRound()
GameManager.loadRound()
GameManager.saveRound()
GameManager.startRound()
RoundManager().searchTarget()
RoundManager().chooseTeam()
RoundManager().chooseBadUnit()
RoundManager().activationGate()
RoundManager().restoreCamera()
RoundManager().nextRound()
TacticalСombat.chooseUnit()
TacticalСombat.moveUnitTo()
TacticalСombat.serachUnit()
TacticalСombat.serachLoot()
TacticalСombat.collectLoot()
TacticalСombat.nextRound(currentRoundManager)
TacticalСombat.atack(currentAtackManager)
TacticalСombat.isTimeUp()
TacticalСombat.getAllUnit() > 0
Тут пока я набросал, уже стало видно какие взаимодействия надо поменять и что некоторые объекты надо поделить еще (слишком много на себя берут, не по роли). Но ты уже сам разберешься. В любом случае проектировать весело, ты буквально думаешь, "о мне нужно тут проверить кончилось ли время - значит мне нужен метод/свойство isTimeUp()". Ты уже мыслишь абстракцией выше - ты не думаешь как ты это сделаешь, ты просто говоришь - тут нужно это и потом это сделаешь.
Это и есть проектирование сверху вниз. Сначала абстракции/взаимодействие - потом код
>>102851
Если что это я по твоей блок-схеме накидал. Это грубая декомпозиция предметной области как есть, без проектирования.
То есть, ты сначала делаешь как лезет в голову, потом смотришь на объекты - и улучшаешь если надо. Я к тому, что вижу все проблемы и что раунд не должен с юнитами работать и TacticalСombat надо поделить итд. Это прототипирование и временно говнить можно, мозг не резиновый
Если что это я по твоей блок-схеме накидал. Это грубая декомпозиция предметной области как есть, без проектирования.
То есть, ты сначала делаешь как лезет в голову, потом смотришь на объекты - и улучшаешь если надо. Я к тому, что вижу все проблемы и что раунд не должен с юнитами работать и TacticalСombat надо поделить итд. Это прототипирование и временно говнить можно, мозг не резиновый
6 Кб, 582x463>>097332 (OP)
Добрый день. С годотом не знаком, но вижу, что на нем в основном 2д-игрули делают.
Подскажите, потянет ли он фпс с графикой уровня второй халвы? С модельками врагов, а не растровыми картинками, как во втором думе, и большими 3д-уровнями на манер старых шутанов.
Добрый день. С годотом не знаком, но вижу, что на нем в основном 2д-игрули делают.
Подскажите, потянет ли он фпс с графикой уровня второй халвы? С модельками врагов, а не растровыми картинками, как во втором думе, и большими 3д-уровнями на манер старых шутанов.
>>102890
Где-то с 3.2 версии уже тянул, лет 5 назад.
Где-то с 3.2 версии уже тянул, лет 5 назад.
>>102890
Godot-то потянет, а ты - потянешь делать 3D модели с анимациями на уровне HL2? Или ты думаешь, что раз движок потянет, то модели у тебя сами появятся? Вот поэтому многие и делают 2D вместо 3D - это проще в большинстве случаев, если ты не кинцо снимаешь и не чужие/ворованные ассеты флипаешь/слопаешь.
Godot-то потянет, а ты - потянешь делать 3D модели с анимациями на уровне HL2? Или ты думаешь, что раз движок потянет, то модели у тебя сами появятся? Вот поэтому многие и делают 2D вместо 3D - это проще в большинстве случаев, если ты не кинцо снимаешь и не чужие/ворованные ассеты флипаешь/слопаешь.
>>102848
Рубрика лайфхаки
Исключений и глобальных функций нет, но можно сделать что типа как на пикчах."xx" это глобальный синглтон, по совместительству сервис-локатор, не спрашивайте почему "xx"
Рубрика лайфхаки
>а лучше как в котлине сделать функцию TODO() которая бросает исключение если забыл имплементировать
Исключений и глобальных функций нет, но можно сделать что типа как на пикчах."xx" это глобальный синглтон, по совместительству сервис-локатор, не спрашивайте почему "xx"
>>102893
Хм, демка выглядит красиво. Значит, с графикой проблем нет. А как насчет масштаба уровней халвы или кваки? Мешей врагов со своими поведенческими скриптами?
>>102923
За кого ты меня принимаешь, за профессионала, что ли?!Нет, конечно! Я сделаю всратые модели и деревянные убогие анимации, это предел. Но помечтать-то можно...
Хм, демка выглядит красиво. Значит, с графикой проблем нет. А как насчет масштаба уровней халвы или кваки? Мешей врагов со своими поведенческими скриптами?
>>102923
>а ты - потянешь делать 3D модели с анимациями на уровне HL2?
За кого ты меня принимаешь, за профессионала, что ли?!Нет, конечно! Я сделаю всратые модели и деревянные убогие анимации, это предел. Но помечтать-то можно...
>>102948
С чего ты решил что вообще могут быть проблемы?
Тебе сказали большинство делает 2Д - потому что это реалистично и достижимо, а не потому что это потолок движка.
У тебя не потянет графику 2004 года, если у тебя будет компьютер 2000 года.
С чего ты решил что вообще могут быть проблемы?
Тебе сказали большинство делает 2Д - потому что это реалистично и достижимо, а не потому что это потолок движка.
У тебя не потянет графику 2004 года, если у тебя будет компьютер 2000 года.
>>102948
Понятия не имею, какие там масштабы. Но если взять, к примеру, GTA 5 или даже GTA SA (оригинал, не переиздание) - чтобы повторить такое на Godot, придётся попотеть со скриптами загрузки-выгрузки чанков карты, потому что из коробки этого механизма нет. Также, хотя в движке есть "auto LOD" (генерирует сразу несколько промежуточных мешей низкого разрешения при импорте меша из gltf формата и автоматически их использует), возможно, тебе придётся вручную настраивать LODы таких вещей, как группа деревьев в лесу или группа соседних зданий. И, конечно, спавн-деспавн машинок и человечков - полностью на тебе, Godot только крутит то, что ты заспавнил, даже если ты заспавнил это за миллионы километров от камеры и игрок этого не видит. На счёт системы оклюдеров у меня большие вопросы, т.к. ещё во времена Godot 3 я их мельком пощупал и не смог разобраться, а в Godot 4 они что-то другое прикрутили... вроде бы. А оклюдеры нужны, чтобы, например, скрывать то, что находится за большим домом или за высоким холмом. Вроде бы разрабы обещали сделать так, чтоб оно автоматически работало, но я не разобрался, как это проверить...
Вкратце - сделать на Godot можно хоть GTA 5 при желании, но потребуется попотеть над своим кодом.
На счёт мешей - в Godot все анимации Skeleton3D пока что происходят только на CPU, поэтому большое число персонажей с анимациями упрётся в предел одного ядра CPU. В "больших" играх/движках данную проблему решают так: запекают анимации в текстуры и воспроизводят их специальным шейдером на GPU, что даёт им какое-то преимущество, особенно с толпой одинаковых внешне зомби или типа того. На Godot подобную оптимизацию тоже можно провернуть, но придётся делать своё решение или искать какой-то аддон.
На счёт скриптов поведения - всё зависит только от тебя. Есть несколько рекомендаций: не использовать _process (только _physics_process и только для движения); не опрашивать ничего из скрипта моба, а ждать сигнала/команды извне; группировать мобов и рассылать команды по одной группе за кадр, чтобы они принимали решения сообща, но размазывали нагрузку от своего думанья на несколько кадров. В общем и целом, для типичного 3D шутера можешь не беспокоиться о нагрузке от скриптов поведения.
Также стоит упомянуть, что если твои мобы будут на основе CharacterBody3D, это может оказаться сильно затратнее, чем на основе RigidBody3D и тем более Area3D, особенно если мобы начнут где-нибудь толпиться (move_and_slide делает кучу лишних проверок коллизий, а проверки коллизий дороже всего там, где много скопившихся физических тел). Но если не делаешь симулятор толпы со 150+ человек в одном месте для древних компов - думаю, можешь не волноваться по этому поводу. Графика начнёт проседать раньше.
Если будешь регулярно этим заниматься, то со временем начнёт получаться всё лучше и лучше. А там поди уже Godot 5.0 выйдет и всё будет хорошо... а твоя игра всё так же на стадии препродакшен-прототипов... Главное - не сидеть и ждать Godot, а делать что-то своими руками и ждать Godot. Смотри не перепутай!
>А как насчет масштаба уровней халвы или кваки?
Понятия не имею, какие там масштабы. Но если взять, к примеру, GTA 5 или даже GTA SA (оригинал, не переиздание) - чтобы повторить такое на Godot, придётся попотеть со скриптами загрузки-выгрузки чанков карты, потому что из коробки этого механизма нет. Также, хотя в движке есть "auto LOD" (генерирует сразу несколько промежуточных мешей низкого разрешения при импорте меша из gltf формата и автоматически их использует), возможно, тебе придётся вручную настраивать LODы таких вещей, как группа деревьев в лесу или группа соседних зданий. И, конечно, спавн-деспавн машинок и человечков - полностью на тебе, Godot только крутит то, что ты заспавнил, даже если ты заспавнил это за миллионы километров от камеры и игрок этого не видит. На счёт системы оклюдеров у меня большие вопросы, т.к. ещё во времена Godot 3 я их мельком пощупал и не смог разобраться, а в Godot 4 они что-то другое прикрутили... вроде бы. А оклюдеры нужны, чтобы, например, скрывать то, что находится за большим домом или за высоким холмом. Вроде бы разрабы обещали сделать так, чтоб оно автоматически работало, но я не разобрался, как это проверить...
Вкратце - сделать на Godot можно хоть GTA 5 при желании, но потребуется попотеть над своим кодом.
>Мешей врагов со своими поведенческими скриптами?
На счёт мешей - в Godot все анимации Skeleton3D пока что происходят только на CPU, поэтому большое число персонажей с анимациями упрётся в предел одного ядра CPU. В "больших" играх/движках данную проблему решают так: запекают анимации в текстуры и воспроизводят их специальным шейдером на GPU, что даёт им какое-то преимущество, особенно с толпой одинаковых внешне зомби или типа того. На Godot подобную оптимизацию тоже можно провернуть, но придётся делать своё решение или искать какой-то аддон.
На счёт скриптов поведения - всё зависит только от тебя. Есть несколько рекомендаций: не использовать _process (только _physics_process и только для движения); не опрашивать ничего из скрипта моба, а ждать сигнала/команды извне; группировать мобов и рассылать команды по одной группе за кадр, чтобы они принимали решения сообща, но размазывали нагрузку от своего думанья на несколько кадров. В общем и целом, для типичного 3D шутера можешь не беспокоиться о нагрузке от скриптов поведения.
Также стоит упомянуть, что если твои мобы будут на основе CharacterBody3D, это может оказаться сильно затратнее, чем на основе RigidBody3D и тем более Area3D, особенно если мобы начнут где-нибудь толпиться (move_and_slide делает кучу лишних проверок коллизий, а проверки коллизий дороже всего там, где много скопившихся физических тел). Но если не делаешь симулятор толпы со 150+ человек в одном месте для древних компов - думаю, можешь не волноваться по этому поводу. Графика начнёт проседать раньше.
>Я сделаю всратые модели и деревянные убогие анимации, это предел. Но помечтать-то можно...
Если будешь регулярно этим заниматься, то со временем начнёт получаться всё лучше и лучше. А там поди уже Godot 5.0 выйдет и всё будет хорошо... а твоя игра всё так же на стадии препродакшен-прототипов... Главное - не сидеть и ждать Godot, а делать что-то своими руками и ждать Godot. Смотри не перепутай!
>>102948
Понятия не имею, какие там масштабы. Но если взять, к примеру, GTA 5 или даже GTA SA (оригинал, не переиздание) - чтобы повторить такое на Godot, придётся попотеть со скриптами загрузки-выгрузки чанков карты, потому что из коробки этого механизма нет. Также, хотя в движке есть "auto LOD" (генерирует сразу несколько промежуточных мешей низкого разрешения при импорте меша из gltf формата и автоматически их использует), возможно, тебе придётся вручную настраивать LODы таких вещей, как группа деревьев в лесу или группа соседних зданий. И, конечно, спавн-деспавн машинок и человечков - полностью на тебе, Godot только крутит то, что ты заспавнил, даже если ты заспавнил это за миллионы километров от камеры и игрок этого не видит. На счёт системы оклюдеров у меня большие вопросы, т.к. ещё во времена Godot 3 я их мельком пощупал и не смог разобраться, а в Godot 4 они что-то другое прикрутили... вроде бы. А оклюдеры нужны, чтобы, например, скрывать то, что находится за большим домом или за высоким холмом. Вроде бы разрабы обещали сделать так, чтоб оно автоматически работало, но я не разобрался, как это проверить...
Вкратце - сделать на Godot можно хоть GTA 5 при желании, но потребуется попотеть над своим кодом.
На счёт мешей - в Godot все анимации Skeleton3D пока что происходят только на CPU, поэтому большое число персонажей с анимациями упрётся в предел одного ядра CPU. В "больших" играх/движках данную проблему решают так: запекают анимации в текстуры и воспроизводят их специальным шейдером на GPU, что даёт им какое-то преимущество, особенно с толпой одинаковых внешне зомби или типа того. На Godot подобную оптимизацию тоже можно провернуть, но придётся делать своё решение или искать какой-то аддон.
На счёт скриптов поведения - всё зависит только от тебя. Есть несколько рекомендаций: не использовать _process (только _physics_process и только для движения); не опрашивать ничего из скрипта моба, а ждать сигнала/команды извне; группировать мобов и рассылать команды по одной группе за кадр, чтобы они принимали решения сообща, но размазывали нагрузку от своего думанья на несколько кадров. В общем и целом, для типичного 3D шутера можешь не беспокоиться о нагрузке от скриптов поведения.
Также стоит упомянуть, что если твои мобы будут на основе CharacterBody3D, это может оказаться сильно затратнее, чем на основе RigidBody3D и тем более Area3D, особенно если мобы начнут где-нибудь толпиться (move_and_slide делает кучу лишних проверок коллизий, а проверки коллизий дороже всего там, где много скопившихся физических тел). Но если не делаешь симулятор толпы со 150+ человек в одном месте для древних компов - думаю, можешь не волноваться по этому поводу. Графика начнёт проседать раньше.
Если будешь регулярно этим заниматься, то со временем начнёт получаться всё лучше и лучше. А там поди уже Godot 5.0 выйдет и всё будет хорошо... а твоя игра всё так же на стадии препродакшен-прототипов... Главное - не сидеть и ждать Godot, а делать что-то своими руками и ждать Godot. Смотри не перепутай!
>А как насчет масштаба уровней халвы или кваки?
Понятия не имею, какие там масштабы. Но если взять, к примеру, GTA 5 или даже GTA SA (оригинал, не переиздание) - чтобы повторить такое на Godot, придётся попотеть со скриптами загрузки-выгрузки чанков карты, потому что из коробки этого механизма нет. Также, хотя в движке есть "auto LOD" (генерирует сразу несколько промежуточных мешей низкого разрешения при импорте меша из gltf формата и автоматически их использует), возможно, тебе придётся вручную настраивать LODы таких вещей, как группа деревьев в лесу или группа соседних зданий. И, конечно, спавн-деспавн машинок и человечков - полностью на тебе, Godot только крутит то, что ты заспавнил, даже если ты заспавнил это за миллионы километров от камеры и игрок этого не видит. На счёт системы оклюдеров у меня большие вопросы, т.к. ещё во времена Godot 3 я их мельком пощупал и не смог разобраться, а в Godot 4 они что-то другое прикрутили... вроде бы. А оклюдеры нужны, чтобы, например, скрывать то, что находится за большим домом или за высоким холмом. Вроде бы разрабы обещали сделать так, чтоб оно автоматически работало, но я не разобрался, как это проверить...
Вкратце - сделать на Godot можно хоть GTA 5 при желании, но потребуется попотеть над своим кодом.
>Мешей врагов со своими поведенческими скриптами?
На счёт мешей - в Godot все анимации Skeleton3D пока что происходят только на CPU, поэтому большое число персонажей с анимациями упрётся в предел одного ядра CPU. В "больших" играх/движках данную проблему решают так: запекают анимации в текстуры и воспроизводят их специальным шейдером на GPU, что даёт им какое-то преимущество, особенно с толпой одинаковых внешне зомби или типа того. На Godot подобную оптимизацию тоже можно провернуть, но придётся делать своё решение или искать какой-то аддон.
На счёт скриптов поведения - всё зависит только от тебя. Есть несколько рекомендаций: не использовать _process (только _physics_process и только для движения); не опрашивать ничего из скрипта моба, а ждать сигнала/команды извне; группировать мобов и рассылать команды по одной группе за кадр, чтобы они принимали решения сообща, но размазывали нагрузку от своего думанья на несколько кадров. В общем и целом, для типичного 3D шутера можешь не беспокоиться о нагрузке от скриптов поведения.
Также стоит упомянуть, что если твои мобы будут на основе CharacterBody3D, это может оказаться сильно затратнее, чем на основе RigidBody3D и тем более Area3D, особенно если мобы начнут где-нибудь толпиться (move_and_slide делает кучу лишних проверок коллизий, а проверки коллизий дороже всего там, где много скопившихся физических тел). Но если не делаешь симулятор толпы со 150+ человек в одном месте для древних компов - думаю, можешь не волноваться по этому поводу. Графика начнёт проседать раньше.
>Я сделаю всратые модели и деревянные убогие анимации, это предел. Но помечтать-то можно...
Если будешь регулярно этим заниматься, то со временем начнёт получаться всё лучше и лучше. А там поди уже Godot 5.0 выйдет и всё будет хорошо... а твоя игра всё так же на стадии препродакшен-прототипов... Главное - не сидеть и ждать Godot, а делать что-то своими руками и ждать Godot. Смотри не перепутай!
>>102965
Почему? Не ну опрашивать из скрипта моба это понятно (не та компетенция), я имею ввиду ты думаешь в каком-нибудь менеджеры в процессах операция вида "if flag:" будут дорогими (если типизирован flag)?
Там скорее будет адок операторов ветвлений, но по производительности это не будет дорогим.
У сигналов тоже есть какая-то диспетчеризация, особенно непросты таймеры. Поэтому я когда увидел как пчел делает стрельбу на таймере - прифигел от такой вольности (может себе позволить).
Вообще, из-за того что мы постоянно крутимся в loop'е, отстрелить себе что-то намного проще чем в каком-нибудь бэкенде. Так же легко можно забыть какие-то пули удалить или партиклы. Отдельно вопрос одноразовых партиклов - не лучше ли пулл держать?? Так же очень легко можно зациклить объекты. А пошаговое удаление массива с начала списка вообще тренд в примерах годота.
В общем, ньюфагу не о том надо переживать, он и без движка себе проблем создаст. А если вайбкодя то и смысла нет, его сам код уже не интересует, у него уже будущее.
>не опрашивать ничего из скрипта моба
Почему? Не ну опрашивать из скрипта моба это понятно (не та компетенция), я имею ввиду ты думаешь в каком-нибудь менеджеры в процессах операция вида "if flag:" будут дорогими (если типизирован flag)?
Там скорее будет адок операторов ветвлений, но по производительности это не будет дорогим.
У сигналов тоже есть какая-то диспетчеризация, особенно непросты таймеры. Поэтому я когда увидел как пчел делает стрельбу на таймере - прифигел от такой вольности (может себе позволить).
Вообще, из-за того что мы постоянно крутимся в loop'е, отстрелить себе что-то намного проще чем в каком-нибудь бэкенде. Так же легко можно забыть какие-то пули удалить или партиклы. Отдельно вопрос одноразовых партиклов - не лучше ли пулл держать?? Так же очень легко можно зациклить объекты. А пошаговое удаление массива с начала списка вообще тренд в примерах годота.
В общем, ньюфагу не о том надо переживать, он и без движка себе проблем создаст. А если вайбкодя то и смысла нет, его сам код уже не интересует, у него уже будущее.
>>102975
Потому что гугли обзоры говнокода YandereDev.
Если у тебя в коде такая портянка:
То ты, скорее всего, не почувствуешь никакой проблемы, пока у тебя только 1 NPC это делает. Но если у тебя 50 NPC, то они все будут выполнять эти инструкции "одновременно" (на самом деле последовательно, но не суть), каждый кадр дёргая какой-то глобальный таймер и проверяя, не пора ли им кушать или идти делать уроки. И это всё накладывается друг на друга и быстро тормозит игру... особенно если у тебя подобным обмазана каждая игровая механика.
Тебе, наверное, кажется это очевидным и глупым, но некоторые (вроде YandereDev) годами пишут такие портянки говнокода и порой даже получают тысячи долларов в месяц за эту работу. Пока их код не сольют и не начнут высмеивать.
Это всё где-то под капотом на C++ зарыто и, вполне возможно, опирается на API операционки.
Но в любом случае, такой код:
Будет в тысячи раз эффективнее. Потому что тут у тебя всего 2 таймера хоть на 100, хоть на 100500 учеников в школе, и просадка частоты кадров будет заметна только когда вся эта толпа ринется в столовку или в класс, а не буквально каждый кадр всё время работы игры. А чтобы избежать резкой просадки в данном случае - делишь школоту на группы и раздаёшь им приказы не сразу, а постепенно, чтоб выдвигались человек по 10 за кадр максимум. Тогда частота кадров и высокая, и стабильная, без скачков.
Просто выводи на экран количество node/object и отдельно orphan nodes:
https://docs.godotengine.org/en/stable/classes/class_performance.html
Тогда легко заметишь "утечку памяти" до того, как переполнится RAM.
В профайлере эта инфа тоже есть, но его отдельно открывать надо...
Если на C# - то лучше пулл, если на GDScript/C++ - то разницы мало. Пулл для пуль и прочих эффектов - это пошло с Unity и C#, потому что у C# сборка мусора с задержкой, и если ты настреляешь миллион пуль, сборщик мусора может затормозить игру до неиграбельного состояния, пока не найдёт и не уничтожит все висящие в памяти ненужные пули. Поэтому на C# пулл - маст хэв, а на нормальных языках нагрузка от удаления и пересоздания объектов не такая большая, так что можно не париться...
Но тут есть маленький нюанс... Godot автоматически удаляет ненужные ресурсы, поэтому с таким кодом:
Ты можешь заметить (особенно на слабом ПК), что это иногда вызывает задержку, в отличие от такого:
Что задержки не вызывает. По-моему, это связано с каким-то ресурсом в системе частиц или шейдеров. В первом варианте кода, происходит удаление не только нод сцены, но и связанных ресурсов, которые используются всеми нодами-клонами этой сцены. То есть, если ты создашь 10 взрывов одновременно, задержки не будет, а если ты создаешь взрыв, дождёшься его удаления, и потом снова создашь, то будет задержка, потому что все ресурсы удалились. Второй вариант кода сохраняет ссылку на образец сцены, которая удерживает в RAM все связанные с ней ресурсы, поэтому взрыв происходит без задержек в любом случае. Я это обнаружил чисто опытным путём - долго голову ломал над "плавающей" задержкой, пока не догадался удерживать ссылку.
Где ты такое видел? Даже в документации написано, что удалять надо с конца. В треде давно как-то проводили замеры - выяснили, что оптимальнее всего развернуть массив задом наперёд через reverse() и удалять с конца, а потом снова сделать reverse(), если тебе обязательно нужно удалить несколько элементов из головы и сохранить порядок. Но, если у тебя очень маленький массив и удаления случаются относительно редко - пофиг вообще, делай так, как будет понятнее в будущем, когда будешь код читать. Как говорится, "преждевременная оптимизация - корень всех зол" или как там... Просто некоторые вещи - это даже не оптимизация, а логичный способ делать вещи (как в случае с таймером, который сигналит школьникам, а не школьники смотрят на часы).
Все компьютерные программы с каким-то интерактивным интерфейсом (GUI и некоторые CLI) "крутятся в loop" в том или ином виде. Разница между циклом GUI программы и циклом игрового приложения в том, что GUI программы в основном "спят" и дожидаются событий операционки, проверяя их раз, скажем, в 100 мс, а игровое приложение каждые <16 мс гоняет различные симуляции, анимации и прочие тяжёлые вещи, помимо стандартного ожидания событий от операционки. Если не ошибаюсь, веб-сервер тоже обязан сидеть и проверять сокеты каждые сколько-то миллисекунд, чтобы успеть открыть соединение с клиентом, разве нет?
Кстати, Godot имеет настройки проекта для оптимизации работы движка под GUI-приложение.
Хочешь больше ньюфагов уровня YandereDev, чтоб движок считали медленным? Если вопрос про скрипты - надо предупредить...
>Почему?
Потому что гугли обзоры говнокода YandereDev.
Если у тебя в коде такая портянка:
>class_name Student extends CharacterBody3D
>func _process(delta: float) -> void:
>_ if Global.time == TIME_FOR_BREAKFAST:
>_ _ move_to(kitchen)
>_ if Global.time == TIME_FOR_CLASSROOM:
>_ _ move_to(classroom)
>_ if ...
То ты, скорее всего, не почувствуешь никакой проблемы, пока у тебя только 1 NPC это делает. Но если у тебя 50 NPC, то они все будут выполнять эти инструкции "одновременно" (на самом деле последовательно, но не суть), каждый кадр дёргая какой-то глобальный таймер и проверяя, не пора ли им кушать или идти делать уроки. И это всё накладывается друг на друга и быстро тормозит игру... особенно если у тебя подобным обмазана каждая игровая механика.
Тебе, наверное, кажется это очевидным и глупым, но некоторые (вроде YandereDev) годами пишут такие портянки говнокода и порой даже получают тысячи долларов в месяц за эту работу. Пока их код не сольют и не начнут высмеивать.
>У сигналов тоже есть какая-то диспетчеризация, особенно непросты таймеры
Это всё где-то под капотом на C++ зарыто и, вполне возможно, опирается на API операционки.
Но в любом случае, такой код:
>func _on_breakfast_timer_timeout() -> void:
>_ move_to(kitchen)
>func _on_classroom_timer_timeout() -> void:
>_ move_to(classroom)
Будет в тысячи раз эффективнее. Потому что тут у тебя всего 2 таймера хоть на 100, хоть на 100500 учеников в школе, и просадка частоты кадров будет заметна только когда вся эта толпа ринется в столовку или в класс, а не буквально каждый кадр всё время работы игры. А чтобы избежать резкой просадки в данном случае - делишь школоту на группы и раздаёшь им приказы не сразу, а постепенно, чтоб выдвигались человек по 10 за кадр максимум. Тогда частота кадров и высокая, и стабильная, без скачков.
>Так же легко можно забыть какие-то пули удалить или партиклы
Просто выводи на экран количество node/object и отдельно orphan nodes:
https://docs.godotengine.org/en/stable/classes/class_performance.html
Тогда легко заметишь "утечку памяти" до того, как переполнится RAM.
В профайлере эта инфа тоже есть, но его отдельно открывать надо...
>Отдельно вопрос одноразовых партиклов - не лучше ли пулл держать??
Если на C# - то лучше пулл, если на GDScript/C++ - то разницы мало. Пулл для пуль и прочих эффектов - это пошло с Unity и C#, потому что у C# сборка мусора с задержкой, и если ты настреляешь миллион пуль, сборщик мусора может затормозить игру до неиграбельного состояния, пока не найдёт и не уничтожит все висящие в памяти ненужные пули. Поэтому на C# пулл - маст хэв, а на нормальных языках нагрузка от удаления и пересоздания объектов не такая большая, так что можно не париться...
Но тут есть маленький нюанс... Godot автоматически удаляет ненужные ресурсы, поэтому с таким кодом:
>var explosion: PackedScene
>func _ready() -> void:
>_ explosion = load("res://explosion.tscn")
>func explode() -> void:
>_ add_child(scene.instantiate())
Ты можешь заметить (особенно на слабом ПК), что это иногда вызывает задержку, в отличие от такого:
>var explosion: Node
>func _ready() -> void:
>_ explosion = load("res://explosion.tscn").instantiate()
>func explode() -> void:
>_ add_child(scene.duplicate())
Что задержки не вызывает. По-моему, это связано с каким-то ресурсом в системе частиц или шейдеров. В первом варианте кода, происходит удаление не только нод сцены, но и связанных ресурсов, которые используются всеми нодами-клонами этой сцены. То есть, если ты создашь 10 взрывов одновременно, задержки не будет, а если ты создаешь взрыв, дождёшься его удаления, и потом снова создашь, то будет задержка, потому что все ресурсы удалились. Второй вариант кода сохраняет ссылку на образец сцены, которая удерживает в RAM все связанные с ней ресурсы, поэтому взрыв происходит без задержек в любом случае. Я это обнаружил чисто опытным путём - долго голову ломал над "плавающей" задержкой, пока не догадался удерживать ссылку.
>пошаговое удаление массива с начала списка
Где ты такое видел? Даже в документации написано, что удалять надо с конца. В треде давно как-то проводили замеры - выяснили, что оптимальнее всего развернуть массив задом наперёд через reverse() и удалять с конца, а потом снова сделать reverse(), если тебе обязательно нужно удалить несколько элементов из головы и сохранить порядок. Но, если у тебя очень маленький массив и удаления случаются относительно редко - пофиг вообще, делай так, как будет понятнее в будущем, когда будешь код читать. Как говорится, "преждевременная оптимизация - корень всех зол" или как там... Просто некоторые вещи - это даже не оптимизация, а логичный способ делать вещи (как в случае с таймером, который сигналит школьникам, а не школьники смотрят на часы).
>из-за того что мы постоянно крутимся в loop
Все компьютерные программы с каким-то интерактивным интерфейсом (GUI и некоторые CLI) "крутятся в loop" в том или ином виде. Разница между циклом GUI программы и циклом игрового приложения в том, что GUI программы в основном "спят" и дожидаются событий операционки, проверяя их раз, скажем, в 100 мс, а игровое приложение каждые <16 мс гоняет различные симуляции, анимации и прочие тяжёлые вещи, помимо стандартного ожидания событий от операционки. Если не ошибаюсь, веб-сервер тоже обязан сидеть и проверять сокеты каждые сколько-то миллисекунд, чтобы успеть открыть соединение с клиентом, разве нет?
Кстати, Godot имеет настройки проекта для оптимизации работы движка под GUI-приложение.
>ньюфагу не о том надо переживать, он и без движка себе проблем создаст
Хочешь больше ньюфагов уровня YandereDev, чтоб движок считали медленным? Если вопрос про скрипты - надо предупредить...
>>102975
Потому что гугли обзоры говнокода YandereDev.
Если у тебя в коде такая портянка:
То ты, скорее всего, не почувствуешь никакой проблемы, пока у тебя только 1 NPC это делает. Но если у тебя 50 NPC, то они все будут выполнять эти инструкции "одновременно" (на самом деле последовательно, но не суть), каждый кадр дёргая какой-то глобальный таймер и проверяя, не пора ли им кушать или идти делать уроки. И это всё накладывается друг на друга и быстро тормозит игру... особенно если у тебя подобным обмазана каждая игровая механика.
Тебе, наверное, кажется это очевидным и глупым, но некоторые (вроде YandereDev) годами пишут такие портянки говнокода и порой даже получают тысячи долларов в месяц за эту работу. Пока их код не сольют и не начнут высмеивать.
Это всё где-то под капотом на C++ зарыто и, вполне возможно, опирается на API операционки.
Но в любом случае, такой код:
Будет в тысячи раз эффективнее. Потому что тут у тебя всего 2 таймера хоть на 100, хоть на 100500 учеников в школе, и просадка частоты кадров будет заметна только когда вся эта толпа ринется в столовку или в класс, а не буквально каждый кадр всё время работы игры. А чтобы избежать резкой просадки в данном случае - делишь школоту на группы и раздаёшь им приказы не сразу, а постепенно, чтоб выдвигались человек по 10 за кадр максимум. Тогда частота кадров и высокая, и стабильная, без скачков.
Просто выводи на экран количество node/object и отдельно orphan nodes:
https://docs.godotengine.org/en/stable/classes/class_performance.html
Тогда легко заметишь "утечку памяти" до того, как переполнится RAM.
В профайлере эта инфа тоже есть, но его отдельно открывать надо...
Если на C# - то лучше пулл, если на GDScript/C++ - то разницы мало. Пулл для пуль и прочих эффектов - это пошло с Unity и C#, потому что у C# сборка мусора с задержкой, и если ты настреляешь миллион пуль, сборщик мусора может затормозить игру до неиграбельного состояния, пока не найдёт и не уничтожит все висящие в памяти ненужные пули. Поэтому на C# пулл - маст хэв, а на нормальных языках нагрузка от удаления и пересоздания объектов не такая большая, так что можно не париться...
Но тут есть маленький нюанс... Godot автоматически удаляет ненужные ресурсы, поэтому с таким кодом:
Ты можешь заметить (особенно на слабом ПК), что это иногда вызывает задержку, в отличие от такого:
Что задержки не вызывает. По-моему, это связано с каким-то ресурсом в системе частиц или шейдеров. В первом варианте кода, происходит удаление не только нод сцены, но и связанных ресурсов, которые используются всеми нодами-клонами этой сцены. То есть, если ты создашь 10 взрывов одновременно, задержки не будет, а если ты создаешь взрыв, дождёшься его удаления, и потом снова создашь, то будет задержка, потому что все ресурсы удалились. Второй вариант кода сохраняет ссылку на образец сцены, которая удерживает в RAM все связанные с ней ресурсы, поэтому взрыв происходит без задержек в любом случае. Я это обнаружил чисто опытным путём - долго голову ломал над "плавающей" задержкой, пока не догадался удерживать ссылку.
Где ты такое видел? Даже в документации написано, что удалять надо с конца. В треде давно как-то проводили замеры - выяснили, что оптимальнее всего развернуть массив задом наперёд через reverse() и удалять с конца, а потом снова сделать reverse(), если тебе обязательно нужно удалить несколько элементов из головы и сохранить порядок. Но, если у тебя очень маленький массив и удаления случаются относительно редко - пофиг вообще, делай так, как будет понятнее в будущем, когда будешь код читать. Как говорится, "преждевременная оптимизация - корень всех зол" или как там... Просто некоторые вещи - это даже не оптимизация, а логичный способ делать вещи (как в случае с таймером, который сигналит школьникам, а не школьники смотрят на часы).
Все компьютерные программы с каким-то интерактивным интерфейсом (GUI и некоторые CLI) "крутятся в loop" в том или ином виде. Разница между циклом GUI программы и циклом игрового приложения в том, что GUI программы в основном "спят" и дожидаются событий операционки, проверяя их раз, скажем, в 100 мс, а игровое приложение каждые <16 мс гоняет различные симуляции, анимации и прочие тяжёлые вещи, помимо стандартного ожидания событий от операционки. Если не ошибаюсь, веб-сервер тоже обязан сидеть и проверять сокеты каждые сколько-то миллисекунд, чтобы успеть открыть соединение с клиентом, разве нет?
Кстати, Godot имеет настройки проекта для оптимизации работы движка под GUI-приложение.
Хочешь больше ньюфагов уровня YandereDev, чтоб движок считали медленным? Если вопрос про скрипты - надо предупредить...
>Почему?
Потому что гугли обзоры говнокода YandereDev.
Если у тебя в коде такая портянка:
>class_name Student extends CharacterBody3D
>func _process(delta: float) -> void:
>_ if Global.time == TIME_FOR_BREAKFAST:
>_ _ move_to(kitchen)
>_ if Global.time == TIME_FOR_CLASSROOM:
>_ _ move_to(classroom)
>_ if ...
То ты, скорее всего, не почувствуешь никакой проблемы, пока у тебя только 1 NPC это делает. Но если у тебя 50 NPC, то они все будут выполнять эти инструкции "одновременно" (на самом деле последовательно, но не суть), каждый кадр дёргая какой-то глобальный таймер и проверяя, не пора ли им кушать или идти делать уроки. И это всё накладывается друг на друга и быстро тормозит игру... особенно если у тебя подобным обмазана каждая игровая механика.
Тебе, наверное, кажется это очевидным и глупым, но некоторые (вроде YandereDev) годами пишут такие портянки говнокода и порой даже получают тысячи долларов в месяц за эту работу. Пока их код не сольют и не начнут высмеивать.
>У сигналов тоже есть какая-то диспетчеризация, особенно непросты таймеры
Это всё где-то под капотом на C++ зарыто и, вполне возможно, опирается на API операционки.
Но в любом случае, такой код:
>func _on_breakfast_timer_timeout() -> void:
>_ move_to(kitchen)
>func _on_classroom_timer_timeout() -> void:
>_ move_to(classroom)
Будет в тысячи раз эффективнее. Потому что тут у тебя всего 2 таймера хоть на 100, хоть на 100500 учеников в школе, и просадка частоты кадров будет заметна только когда вся эта толпа ринется в столовку или в класс, а не буквально каждый кадр всё время работы игры. А чтобы избежать резкой просадки в данном случае - делишь школоту на группы и раздаёшь им приказы не сразу, а постепенно, чтоб выдвигались человек по 10 за кадр максимум. Тогда частота кадров и высокая, и стабильная, без скачков.
>Так же легко можно забыть какие-то пули удалить или партиклы
Просто выводи на экран количество node/object и отдельно orphan nodes:
https://docs.godotengine.org/en/stable/classes/class_performance.html
Тогда легко заметишь "утечку памяти" до того, как переполнится RAM.
В профайлере эта инфа тоже есть, но его отдельно открывать надо...
>Отдельно вопрос одноразовых партиклов - не лучше ли пулл держать??
Если на C# - то лучше пулл, если на GDScript/C++ - то разницы мало. Пулл для пуль и прочих эффектов - это пошло с Unity и C#, потому что у C# сборка мусора с задержкой, и если ты настреляешь миллион пуль, сборщик мусора может затормозить игру до неиграбельного состояния, пока не найдёт и не уничтожит все висящие в памяти ненужные пули. Поэтому на C# пулл - маст хэв, а на нормальных языках нагрузка от удаления и пересоздания объектов не такая большая, так что можно не париться...
Но тут есть маленький нюанс... Godot автоматически удаляет ненужные ресурсы, поэтому с таким кодом:
>var explosion: PackedScene
>func _ready() -> void:
>_ explosion = load("res://explosion.tscn")
>func explode() -> void:
>_ add_child(scene.instantiate())
Ты можешь заметить (особенно на слабом ПК), что это иногда вызывает задержку, в отличие от такого:
>var explosion: Node
>func _ready() -> void:
>_ explosion = load("res://explosion.tscn").instantiate()
>func explode() -> void:
>_ add_child(scene.duplicate())
Что задержки не вызывает. По-моему, это связано с каким-то ресурсом в системе частиц или шейдеров. В первом варианте кода, происходит удаление не только нод сцены, но и связанных ресурсов, которые используются всеми нодами-клонами этой сцены. То есть, если ты создашь 10 взрывов одновременно, задержки не будет, а если ты создаешь взрыв, дождёшься его удаления, и потом снова создашь, то будет задержка, потому что все ресурсы удалились. Второй вариант кода сохраняет ссылку на образец сцены, которая удерживает в RAM все связанные с ней ресурсы, поэтому взрыв происходит без задержек в любом случае. Я это обнаружил чисто опытным путём - долго голову ломал над "плавающей" задержкой, пока не догадался удерживать ссылку.
>пошаговое удаление массива с начала списка
Где ты такое видел? Даже в документации написано, что удалять надо с конца. В треде давно как-то проводили замеры - выяснили, что оптимальнее всего развернуть массив задом наперёд через reverse() и удалять с конца, а потом снова сделать reverse(), если тебе обязательно нужно удалить несколько элементов из головы и сохранить порядок. Но, если у тебя очень маленький массив и удаления случаются относительно редко - пофиг вообще, делай так, как будет понятнее в будущем, когда будешь код читать. Как говорится, "преждевременная оптимизация - корень всех зол" или как там... Просто некоторые вещи - это даже не оптимизация, а логичный способ делать вещи (как в случае с таймером, который сигналит школьникам, а не школьники смотрят на часы).
>из-за того что мы постоянно крутимся в loop
Все компьютерные программы с каким-то интерактивным интерфейсом (GUI и некоторые CLI) "крутятся в loop" в том или ином виде. Разница между циклом GUI программы и циклом игрового приложения в том, что GUI программы в основном "спят" и дожидаются событий операционки, проверяя их раз, скажем, в 100 мс, а игровое приложение каждые <16 мс гоняет различные симуляции, анимации и прочие тяжёлые вещи, помимо стандартного ожидания событий от операционки. Если не ошибаюсь, веб-сервер тоже обязан сидеть и проверять сокеты каждые сколько-то миллисекунд, чтобы успеть открыть соединение с клиентом, разве нет?
Кстати, Godot имеет настройки проекта для оптимизации работы движка под GUI-приложение.
>ньюфагу не о том надо переживать, он и без движка себе проблем создаст
Хочешь больше ньюфагов уровня YandereDev, чтоб движок считали медленным? Если вопрос про скрипты - надо предупредить...
>>102988
А, не гугли, там ничего полезного. Я и сам не смотрел их, лол, только картинки-мемы листал в своё время. Но вот этот мем с опросом общего таймера каждым школьником каждый кадр пробивает на смешок уже сколько, лет шесть?.. Не делайте так...
TL;DR: оптимизация алгоритма >>>> оптимизация языка/интерпретатора/компилятора.
>гугли обзоры говнокода YandereDev
А, не гугли, там ничего полезного. Я и сам не смотрел их, лол, только картинки-мемы листал в своё время. Но вот этот мем с опросом общего таймера каждым школьником каждый кадр пробивает на смешок уже сколько, лет шесть?.. Не делайте так...
TL;DR: оптимизация алгоритма >>>> оптимизация языка/интерпретатора/компилятора.
>>102988
Ну
if Global.time == TIME_FOR_BREAKFAST:
Смотри у тебя было реально там 10 юнитов и ты не чувствовал проблему. А потом делаешь следующую игру - у тебя 150 юнитов и ты ощущаешь лаг в моменте. Только теперь это стало плохим решением. Но это решение все еще масштабируется. Ты заводишь условный Баланс-менеджер в котором есть информация кто и как должен распределиться и получается следующий код (это плохой код, просто показываю следующий возможный шаг)
if BalanceManager.canExecute(self, status, delta)
Но важно - лаг возникает не из-за проверок if...else, и от BalanceManager, которые сложнее (там хэшмапа и пару if...else - это все еще быстро), а возникает именно из-за задачи, которую они будут выполнять.
То есть, сигналы тут практичнее, но проблема то в том, что сейчас в один момент у тебя будет 150 поисков пути! Вот где закрадывается проблема, сигналы не как не решают саму проблему, а даже немного скрывают (потому что логика начинает размазываться по сигналами и если сразу же будут еще сигналы или их очень много это будет почти GOTO лапша).
В то время ты раз написал балансировщик и не паришься.
_ready()
# Очень легкое каждый тик (обычно тик равен 60/секунду)
__TickManager.registerOneTick(self, liteTaskMethod)
# Что-то потяжелее, каждые 250 тиков (~4,16 сек)
__TickManager.registerTick250(self, rareTaskMethod)
# Очень редко, например рост растений, проверка гниения раз 2000 тиков (~33 сек)
__TickManager.registerTick2000(self, longTaskMethod)
Это, кстати, тики из римки, я бы сделал кратное "60" (240, 2400), но кто поймет гения.
Все, теперь проблемы вообще нет, мы регистрируем методы куда нужно, например делаем Tick60 (раз в секунду) для поиска пути и просто закидываем метод в тик менеджер. Надо учесть что внутри тик менеджер не просто складывает все в мапу, он еще делает смешение по времени, чтобы тот же Tick60 не запустил все таски в конце секунды, а тоже размазал по времени.
Можно пойти дальше, ты можешь даже регистрировать насколько сейчас перегружена игра и что-то распределять по другому, но главное это уже проблема твоего тик менеджера, а не логики юнита (конечно твоя проблема, мы просто делегировали проблему другому модулю, но если там написано хорошо, то ты уже не думаешь об этом так глубоко, теперь тебе надо только раскидать по таскам твои активные методы).
В общем, есть такая проблема в разработке называется "преждевременная оптимизация корень всех зол" (гуглится, кому надо), программисты очень часто оптимизируют там где проблемы не было, буквально тратят тонну ресурсов/времени экономия на спичках, когда узкое горлышко видно только через профайлер/замеры, так что вариант
if Global.time == TIME_FOR_BREAKFAST
Не говнокод, это просто решение для простой задачи - тут не нужно абстракций (сигналы, менеджера) если не нужно оптимизаций. Главное что этот код проще сопровождать.
Ну
if Global.time == TIME_FOR_BREAKFAST:
Смотри у тебя было реально там 10 юнитов и ты не чувствовал проблему. А потом делаешь следующую игру - у тебя 150 юнитов и ты ощущаешь лаг в моменте. Только теперь это стало плохим решением. Но это решение все еще масштабируется. Ты заводишь условный Баланс-менеджер в котором есть информация кто и как должен распределиться и получается следующий код (это плохой код, просто показываю следующий возможный шаг)
if BalanceManager.canExecute(self, status, delta)
Но важно - лаг возникает не из-за проверок if...else, и от BalanceManager, которые сложнее (там хэшмапа и пару if...else - это все еще быстро), а возникает именно из-за задачи, которую они будут выполнять.
То есть, сигналы тут практичнее, но проблема то в том, что сейчас в один момент у тебя будет 150 поисков пути! Вот где закрадывается проблема, сигналы не как не решают саму проблему, а даже немного скрывают (потому что логика начинает размазываться по сигналами и если сразу же будут еще сигналы или их очень много это будет почти GOTO лапша).
В то время ты раз написал балансировщик и не паришься.
_ready()
# Очень легкое каждый тик (обычно тик равен 60/секунду)
__TickManager.registerOneTick(self, liteTaskMethod)
# Что-то потяжелее, каждые 250 тиков (~4,16 сек)
__TickManager.registerTick250(self, rareTaskMethod)
# Очень редко, например рост растений, проверка гниения раз 2000 тиков (~33 сек)
__TickManager.registerTick2000(self, longTaskMethod)
Это, кстати, тики из римки, я бы сделал кратное "60" (240, 2400), но кто поймет гения.
Все, теперь проблемы вообще нет, мы регистрируем методы куда нужно, например делаем Tick60 (раз в секунду) для поиска пути и просто закидываем метод в тик менеджер. Надо учесть что внутри тик менеджер не просто складывает все в мапу, он еще делает смешение по времени, чтобы тот же Tick60 не запустил все таски в конце секунды, а тоже размазал по времени.
Можно пойти дальше, ты можешь даже регистрировать насколько сейчас перегружена игра и что-то распределять по другому, но главное это уже проблема твоего тик менеджера, а не логики юнита (конечно твоя проблема, мы просто делегировали проблему другому модулю, но если там написано хорошо, то ты уже не думаешь об этом так глубоко, теперь тебе надо только раскидать по таскам твои активные методы).
В общем, есть такая проблема в разработке называется "преждевременная оптимизация корень всех зол" (гуглится, кому надо), программисты очень часто оптимизируют там где проблемы не было, буквально тратят тонну ресурсов/времени экономия на спичках, когда узкое горлышко видно только через профайлер/замеры, так что вариант
if Global.time == TIME_FOR_BREAKFAST
Не говнокод, это просто решение для простой задачи - тут не нужно абстракций (сигналы, менеджера) если не нужно оптимизаций. Главное что этот код проще сопровождать.
>>102988
Ну
if Global.time == TIME_FOR_BREAKFAST:
Смотри у тебя было реально там 10 юнитов и ты не чувствовал проблему. А потом делаешь следующую игру - у тебя 150 юнитов и ты ощущаешь лаг в моменте. Только теперь это стало плохим решением. Но это решение все еще масштабируется. Ты заводишь условный Баланс-менеджер в котором есть информация кто и как должен распределиться и получается следующий код (это плохой код, просто показываю следующий возможный шаг)
if BalanceManager.canExecute(self, status, delta)
Но важно - лаг возникает не из-за проверок if...else, и от BalanceManager, которые сложнее (там хэшмапа и пару if...else - это все еще быстро), а возникает именно из-за задачи, которую они будут выполнять.
То есть, сигналы тут практичнее, но проблема то в том, что сейчас в один момент у тебя будет 150 поисков пути! Вот где закрадывается проблема, сигналы не как не решают саму проблему, а даже немного скрывают (потому что логика начинает размазываться по сигналами и если сразу же будут еще сигналы или их очень много это будет почти GOTO лапша).
В то время ты раз написал балансировщик и не паришься.
_ready()
# Очень легкое каждый тик (обычно тик равен 60/секунду)
__TickManager.registerOneTick(self, liteTaskMethod)
# Что-то потяжелее, каждые 250 тиков (~4,16 сек)
__TickManager.registerTick250(self, rareTaskMethod)
# Очень редко, например рост растений, проверка гниения раз 2000 тиков (~33 сек)
__TickManager.registerTick2000(self, longTaskMethod)
Это, кстати, тики из римки, я бы сделал кратное "60" (240, 2400), но кто поймет гения.
Все, теперь проблемы вообще нет, мы регистрируем методы куда нужно, например делаем Tick60 (раз в секунду) для поиска пути и просто закидываем метод в тик менеджер. Надо учесть что внутри тик менеджер не просто складывает все в мапу, он еще делает смешение по времени, чтобы тот же Tick60 не запустил все таски в конце секунды, а тоже размазал по времени.
Можно пойти дальше, ты можешь даже регистрировать насколько сейчас перегружена игра и что-то распределять по другому, но главное это уже проблема твоего тик менеджера, а не логики юнита (конечно твоя проблема, мы просто делегировали проблему другому модулю, но если там написано хорошо, то ты уже не думаешь об этом так глубоко, теперь тебе надо только раскидать по таскам твои активные методы).
В общем, есть такая проблема в разработке называется "преждевременная оптимизация корень всех зол" (гуглится, кому надо), программисты очень часто оптимизируют там где проблемы не было, буквально тратят тонну ресурсов/времени экономия на спичках, когда узкое горлышко видно только через профайлер/замеры, так что вариант
if Global.time == TIME_FOR_BREAKFAST
Не говнокод, это просто решение для простой задачи - тут не нужно абстракций (сигналы, менеджера) если не нужно оптимизаций. Главное что этот код проще сопровождать.
Ну
if Global.time == TIME_FOR_BREAKFAST:
Смотри у тебя было реально там 10 юнитов и ты не чувствовал проблему. А потом делаешь следующую игру - у тебя 150 юнитов и ты ощущаешь лаг в моменте. Только теперь это стало плохим решением. Но это решение все еще масштабируется. Ты заводишь условный Баланс-менеджер в котором есть информация кто и как должен распределиться и получается следующий код (это плохой код, просто показываю следующий возможный шаг)
if BalanceManager.canExecute(self, status, delta)
Но важно - лаг возникает не из-за проверок if...else, и от BalanceManager, которые сложнее (там хэшмапа и пару if...else - это все еще быстро), а возникает именно из-за задачи, которую они будут выполнять.
То есть, сигналы тут практичнее, но проблема то в том, что сейчас в один момент у тебя будет 150 поисков пути! Вот где закрадывается проблема, сигналы не как не решают саму проблему, а даже немного скрывают (потому что логика начинает размазываться по сигналами и если сразу же будут еще сигналы или их очень много это будет почти GOTO лапша).
В то время ты раз написал балансировщик и не паришься.
_ready()
# Очень легкое каждый тик (обычно тик равен 60/секунду)
__TickManager.registerOneTick(self, liteTaskMethod)
# Что-то потяжелее, каждые 250 тиков (~4,16 сек)
__TickManager.registerTick250(self, rareTaskMethod)
# Очень редко, например рост растений, проверка гниения раз 2000 тиков (~33 сек)
__TickManager.registerTick2000(self, longTaskMethod)
Это, кстати, тики из римки, я бы сделал кратное "60" (240, 2400), но кто поймет гения.
Все, теперь проблемы вообще нет, мы регистрируем методы куда нужно, например делаем Tick60 (раз в секунду) для поиска пути и просто закидываем метод в тик менеджер. Надо учесть что внутри тик менеджер не просто складывает все в мапу, он еще делает смешение по времени, чтобы тот же Tick60 не запустил все таски в конце секунды, а тоже размазал по времени.
Можно пойти дальше, ты можешь даже регистрировать насколько сейчас перегружена игра и что-то распределять по другому, но главное это уже проблема твоего тик менеджера, а не логики юнита (конечно твоя проблема, мы просто делегировали проблему другому модулю, но если там написано хорошо, то ты уже не думаешь об этом так глубоко, теперь тебе надо только раскидать по таскам твои активные методы).
В общем, есть такая проблема в разработке называется "преждевременная оптимизация корень всех зол" (гуглится, кому надо), программисты очень часто оптимизируют там где проблемы не было, буквально тратят тонну ресурсов/времени экономия на спичках, когда узкое горлышко видно только через профайлер/замеры, так что вариант
if Global.time == TIME_FOR_BREAKFAST
Не говнокод, это просто решение для простой задачи - тут не нужно абстракций (сигналы, менеджера) если не нужно оптимизаций. Главное что этот код проще сопровождать.
>>103031
Но это то же самое, что и "сигналы"...
Смысл же в том, что _process() выполняется каждый кадр - если игра рендерит 100 кадров в секунду, тогда _process() вызывается 100 раз за секунду у каждой ноды, а если у нас 100 нод - это уже 10 тысячи _process() в секунду. Если ты 10 тысяч раз в секунду делаешь какую-то БЕССМЫСЛЕННУЮ проверку, то это всё будет складываться и уже не будет "экономией на спичках", нет? Ведь даже если одна проверка происходит за 0.0001 мс, то 10 тысяч таких проверок - это уже +1 мс к твоему времени кадра, а это много. А твой TickManager делает эту проверку 1 раз за 2000 тиков для ВСЕХ нод, которые у него зарегистрировались, и только когда эта проверка срабатывает, только тогда он передаёт им команду выполнить что-то, что им нужно выполнять раз в 2000 тиков.
Также нужно помнить, что в Godot даже пустой _process() нагружает движок, и лучше делать set_process(false), если ты зачем-то объявил _process() в своём коде, но не используешь его 99% времени. Конечно, это начинает проявлять себя только когда у тебя достаточно много таких нод, но всё равно стоит иметь в виду.
А то накодят такого, а потом "ваш недопитон слишком медленный"...
>TickManager.registerTick2000(self, longTaskMethod)
Но это то же самое, что и "сигналы"...
Смысл же в том, что _process() выполняется каждый кадр - если игра рендерит 100 кадров в секунду, тогда _process() вызывается 100 раз за секунду у каждой ноды, а если у нас 100 нод - это уже 10 тысячи _process() в секунду. Если ты 10 тысяч раз в секунду делаешь какую-то БЕССМЫСЛЕННУЮ проверку, то это всё будет складываться и уже не будет "экономией на спичках", нет? Ведь даже если одна проверка происходит за 0.0001 мс, то 10 тысяч таких проверок - это уже +1 мс к твоему времени кадра, а это много. А твой TickManager делает эту проверку 1 раз за 2000 тиков для ВСЕХ нод, которые у него зарегистрировались, и только когда эта проверка срабатывает, только тогда он передаёт им команду выполнить что-то, что им нужно выполнять раз в 2000 тиков.
Также нужно помнить, что в Godot даже пустой _process() нагружает движок, и лучше делать set_process(false), если ты зачем-то объявил _process() в своём коде, но не используешь его 99% времени. Конечно, это начинает проявлять себя только когда у тебя достаточно много таких нод, но всё равно стоит иметь в виду.
А то накодят такого, а потом "ваш недопитон слишком медленный"...
>>102988
Ну вот как-будто для чего-то частого захочется написать один раз какой-то пулл который бы имел в запасе n-объектов, а если надо расширялся (сохраняя размер, или если надо сжимался обратно). Подсчет ссылок тоже прям не совсем дешевый, лишний раз аллоцировать тоже не хочется
Да, потому что как раз аллоцируется новый массив каждый раз. Такое лучше не замерять, а один раз прочитать про "Сложность алгоритмов", на хабре вроде была хорошая статья.
Я для поиска пути хранил индекс не трогая массив вообще. Позже это еще оказалось удачным решением, потому что в нескольких алгоритмов требовалось посмотреть на предыдущий гекс. Это чем-то напоминает работу с seek в файловом дескрипторе, где как-будто катаешься туда-сюда по магнитной ленте (я не такой старый)
Это не так, иначе проц улетал бы. Там устроенно на прерываниях. Все буквально спят.
Вот интересно глянуть как устроен таймер в годот.
Да он крутиться в цикле, но "зависает" на методе ожидающий результата прерывания (от сетевой карты), поэтому в простое ничего не жрет вообще.
Это чем-то напоминает ожидания сигнала на await - корутина просто спит. Спящих 100.000 корутин не должны грузить никак (пока не придет сигнал).
Я иногда намеренно пишу простой код (который по совместительству говнокод). Сопровождение кода важнее понтов (принципы KISS и YAGNI).
>долго голову ломал над "плавающей" задержкой, пока не догадался удерживать ссылку.
Ну вот как-будто для чего-то частого захочется написать один раз какой-то пулл который бы имел в запасе n-объектов, а если надо расширялся (сохраняя размер, или если надо сжимался обратно). Подсчет ссылок тоже прям не совсем дешевый, лишний раз аллоцировать тоже не хочется
> Даже в документации написано, что удалять надо с конца. В треде давно как-то проводили замеры
Да, потому что как раз аллоцируется новый массив каждый раз. Такое лучше не замерять, а один раз прочитать про "Сложность алгоритмов", на хабре вроде была хорошая статья.
>реверс
Я для поиска пути хранил индекс не трогая массив вообще. Позже это еще оказалось удачным решением, потому что в нескольких алгоритмов требовалось посмотреть на предыдущий гекс. Это чем-то напоминает работу с seek в файловом дескрипторе, где как-будто катаешься туда-сюда по магнитной ленте (я не такой старый)
>Разница между циклом GUI программы и циклом игрового приложения в том, что GUI программы в основном "спят" и дожидаются событий операционки, проверяя их раз, скажем, в 100 мс
Это не так, иначе проц улетал бы. Там устроенно на прерываниях. Все буквально спят.
Вот интересно глянуть как устроен таймер в годот.
>Если не ошибаюсь, веб-сервер тоже обязан сидеть и проверять сокеты каждые сколько-то миллисекунд, чтобы успеть открыть соединение с клиентом, разве нет?
Да он крутиться в цикле, но "зависает" на методе ожидающий результата прерывания (от сетевой карты), поэтому в простое ничего не жрет вообще.
Это чем-то напоминает ожидания сигнала на await - корутина просто спит. Спящих 100.000 корутин не должны грузить никак (пока не придет сигнал).
>Хочешь больше ньюфагов уровня YandereDev
Я иногда намеренно пишу простой код (который по совместительству говнокод). Сопровождение кода важнее понтов (принципы KISS и YAGNI).
33 Кб, 903x516>>103034
Да это фактически регистрация хендлеров у системный ивентов.
Только тут вся логика нагрузки и распределения в одном месте, а не в сигналах.
>>103034
Вот, как раз тики и нужны, у них своя частота (TPS), прям как у _physics_process свои тики. То есть, при 144Hz у тебя все равно будет 60 TPS на секунду.
Я как-то тут ныл что хочу переписать тикменеджер на С++, но надо тестить, как-будто я могу получить нефига. if...else там должны занимать наносекунды - вы
>>103034
Насколько я помню, если ты не имплементировал в скрипте виртуальный метод _process - движок сам исключит его.
Да, вызов функции дороже условия if в 10 раз. А разница между if и emit'ом в 60раз!
Но чел, это наносекунды, не парься за эту хрень. Один блядский пасфаендер убьет все твои милларды Ifов и миллионы сигналов (утрирую, но могу показать как его колбасит на картах 250х250).
>Но это то же самое, что и "сигналы"...
Да это фактически регистрация хендлеров у системный ивентов.
Только тут вся логика нагрузки и распределения в одном месте, а не в сигналах.
>>103034
>Смысл же в том, что _process() выполняется каждый кадр
Вот, как раз тики и нужны, у них своя частота (TPS), прям как у _physics_process свои тики. То есть, при 144Hz у тебя все равно будет 60 TPS на секунду.
Я как-то тут ныл что хочу переписать тикменеджер на С++, но надо тестить, как-будто я могу получить нефига. if...else там должны занимать наносекунды - вы
>>103034
>Также нужно помнить, что в Godot даже пустой _process() нагружает движок, и лучше делать set_process(false),
Насколько я помню, если ты не имплементировал в скрипте виртуальный метод _process - движок сам исключит его.
Да, вызов функции дороже условия if в 10 раз. А разница между if и emit'ом в 60раз!
Но чел, это наносекунды, не парься за эту хрень. Один блядский пасфаендер убьет все твои милларды Ifов и миллионы сигналов (утрирую, но могу показать как его колбасит на картах 250х250).
>>103036
У тебя когнитивное искажение по поводу производительности (без агрессии). Операторы трогать вообще не нужно, надо только думать об аллокациях, обычно проблема в этом.
Я тоже когда-то все замерял в пхп, до сих пор помню, что
variable++
obj->variable++
7 раз медленнее (тоже наносекунды там). Но какая в этом разница, когда мы суммарно на БД висим и спим 100мс. Хоть раст или С++ принеси туда, все равно спишь на вводе/выводе больше время или пинге. ну это я уже о своем наныл, просто не нужно "экономить на спичках".
У тебя когнитивное искажение по поводу производительности (без агрессии). Операторы трогать вообще не нужно, надо только думать об аллокациях, обычно проблема в этом.
Я тоже когда-то все замерял в пхп, до сих пор помню, что
variable++
obj->variable++
7 раз медленнее (тоже наносекунды там). Но какая в этом разница, когда мы суммарно на БД висим и спим 100мс. Хоть раст или С++ принеси туда, все равно спишь на вводе/выводе больше время или пинге. ну это я уже о своем наныл, просто не нужно "экономить на спичках".
>>103038
пинг тоже i/o - но кому не пофиг
Я не нашел ту старую классную табличку с восприятием времени. Но примерно/
Если представить что 1 наносекунда это 1 секунда.
То операция if занимала бы 5 секунд. Доступ к памяти почти две минуты. То есть, прочитать из памяти дороже операции if (и арифметики) в ~20раз!
Доступ к жесткому диску (HDD) вообще две недели.
А одна секунда времени было бы 31,7 лет
PS поиск пути в 62000 клеток от края до края на сложной местности занял бы 231 день. А ты переживаешь за 5 секунд if bool
>вводе/выводе больше время или пинге
пинг тоже i/o - но кому не пофиг
Я не нашел ту старую классную табличку с восприятием времени. Но примерно/
Если представить что 1 наносекунда это 1 секунда.
То операция if занимала бы 5 секунд. Доступ к памяти почти две минуты. То есть, прочитать из памяти дороже операции if (и арифметики) в ~20раз!
Доступ к жесткому диску (HDD) вообще две недели.
А одна секунда времени было бы 31,7 лет
PS поиск пути в 62000 клеток от края до края на сложной местности занял бы 231 день. А ты переживаешь за 5 секунд if bool
>>103039
Я наврал, я перепутал 2,3 дня.
В общем, самое интересное, что 1 кадр в 0.016 - это 193 дней
>PS поиск пути в 62000 клеток от края до края на сложной местности занял бы 231 день.
Я наврал, я перепутал 2,3 дня.
В общем, самое интересное, что 1 кадр в 0.016 - это 193 дней
>>103034
Ты бы ужаснулся, но каждый кадр там перебираться все хендлеры! Это можно сделать в будущем лучше, но на этапе прототипа это копейки. Заметь, мы можем менять и перестраивать тик менеджер, переписать даже на С++ (сделать разные и сравнить), но игровая логика уже никак не будет меняться, в этом сила сервисов/менеджера, мы инкапсулируем кишки, получая поверх API которое не будет меняться (но можно заменить алгоритмы).
Кстати, если предать усилия - можно сделать копию римки, которая не будет так сильно лагать. Прикинь, школота бв в движкосрачнике прифигела и бегала - мол, около-клон на годоте работает лучше чем на U (мне думается, можно получить на порядок)! Но мы то будем знать, что вся заслуга в оптимизации и алгоритмах.
>Ведь даже если одна проверка происходит за 0.0001 мс, то 10 тысяч таких проверок - это уже +1 мс к твоему времени кадра, а это много
Ты бы ужаснулся, но каждый кадр там перебираться все хендлеры! Это можно сделать в будущем лучше, но на этапе прототипа это копейки. Заметь, мы можем менять и перестраивать тик менеджер, переписать даже на С++ (сделать разные и сравнить), но игровая логика уже никак не будет меняться, в этом сила сервисов/менеджера, мы инкапсулируем кишки, получая поверх API которое не будет меняться (но можно заменить алгоритмы).
Кстати, если предать усилия - можно сделать копию римки, которая не будет так сильно лагать. Прикинь, школота бв в движкосрачнике прифигела и бегала - мол, около-клон на годоте работает лучше чем на U (мне думается, можно получить на порядок)! Но мы то будем знать, что вся заслуга в оптимизации и алгоритмах.
5 Кб, 235x62Оказывается Годони хорошо узнает линки (mklink /J)
Живите с этим. но лучше используйте git
Живите с этим. но лучше используйте git
>>103150
Junction Point
Честно говоря впервые использую ссылки на винде, тут они немного другие.
Git - Submodules будут практичнее, но пока прототипы не заслужили место на гите.
>софтлинки? хардлинки?
Junction Point
Честно говоря впервые использую ссылки на винде, тут они немного другие.
Git - Submodules будут практичнее, но пока прототипы не заслужили место на гите.
>>103036
Недостаток приёма с "пуллом" в том, что тебе придётся постоянно сбрасывать все параметры твоих объектов в пулле к значениям по умолчанию, иначе могут появиться неприятные баги, которые трудно заметить и поймать. А если ты каждый раз создаёшь новый объект (или дублируешь объект-прототип), то все параметры гарантированно будут в состоянии по умолчанию, и тебе не придётся ручками куда-то записывать вещи типа "value = default_value".
Вообще-то, удаление элементов с начала массива приводит к циклу for, который пробегается по всей длине массива и переносит значения элементов на -1 назад, а потом длина массива сокращается на -1. Поэтому, чем твой массив длиннее, тем более затратно удаления с начала массива. Никакой новой аллокации не происходит - массив остаётся на своём месте в памяти. Уж не знаю, почему нельзя перенести указатель начала массива на +1, уменьшив длину на -1.
Godot тоже "спит", и длительность "сна" можно настроить в настройках проекта.
>>103037
Зачем ты галлюцинации нейроночные постишь? Сам замерь, если так надо.
>>103039
Только речь шла о миллиардах или триллионах "if bool" каждую секунду.
И откуда этот bool берётся? Может, там целая матрёшка запросов куда-то.
>>103120
Это всё просто прекрасно, а что с игрой? Где игра?
>>103149
Зачем всё это? Игры делаются и без этого.
По-хорошему, Godot давно нужна локальная библиотека аддонов, чтобы юзер мог сваливать все свои аддоны в одну папку вне папки текущего проекта, а в настройках проекта подключать нужные аддоны одной галочкой, и чтобы они не копировались никуда, а оставались в библиотеке. Если в локальной аддона нет - он скачивается из интернета. Ну и, разумеется, в настройках проекта указывается версия аддона, если обновляться до актуальной почему-то не выходит.
>для чего-то частого захочется написать один раз какой-то пулл
Недостаток приёма с "пуллом" в том, что тебе придётся постоянно сбрасывать все параметры твоих объектов в пулле к значениям по умолчанию, иначе могут появиться неприятные баги, которые трудно заметить и поймать. А если ты каждый раз создаёшь новый объект (или дублируешь объект-прототип), то все параметры гарантированно будут в состоянии по умолчанию, и тебе не придётся ручками куда-то записывать вещи типа "value = default_value".
>как раз аллоцируется новый массив каждый раз
Вообще-то, удаление элементов с начала массива приводит к циклу for, который пробегается по всей длине массива и переносит значения элементов на -1 назад, а потом длина массива сокращается на -1. Поэтому, чем твой массив длиннее, тем более затратно удаления с начала массива. Никакой новой аллокации не происходит - массив остаётся на своём месте в памяти. Уж не знаю, почему нельзя перенести указатель начала массива на +1, уменьшив длину на -1.
>Там устроенно на прерываниях. Все буквально спят.
Godot тоже "спит", и длительность "сна" можно настроить в настройках проекта.
>>103037
Зачем ты галлюцинации нейроночные постишь? Сам замерь, если так надо.
>>103039
>А ты переживаешь за 5 секунд if bool
Только речь шла о миллиардах или триллионах "if bool" каждую секунду.
И откуда этот bool берётся? Может, там целая матрёшка запросов куда-то.
>>103120
>можем менять и перестраивать тик менеджер
Это всё просто прекрасно, а что с игрой? Где игра?
>>103149
Зачем всё это? Игры делаются и без этого.
По-хорошему, Godot давно нужна локальная библиотека аддонов, чтобы юзер мог сваливать все свои аддоны в одну папку вне папки текущего проекта, а в настройках проекта подключать нужные аддоны одной галочкой, и чтобы они не копировались никуда, а оставались в библиотеке. Если в локальной аддона нет - он скачивается из интернета. Ну и, разумеется, в настройках проекта указывается версия аддона, если обновляться до актуальной почему-то не выходит.
>>103036
Недостаток приёма с "пуллом" в том, что тебе придётся постоянно сбрасывать все параметры твоих объектов в пулле к значениям по умолчанию, иначе могут появиться неприятные баги, которые трудно заметить и поймать. А если ты каждый раз создаёшь новый объект (или дублируешь объект-прототип), то все параметры гарантированно будут в состоянии по умолчанию, и тебе не придётся ручками куда-то записывать вещи типа "value = default_value".
Вообще-то, удаление элементов с начала массива приводит к циклу for, который пробегается по всей длине массива и переносит значения элементов на -1 назад, а потом длина массива сокращается на -1. Поэтому, чем твой массив длиннее, тем более затратно удаления с начала массива. Никакой новой аллокации не происходит - массив остаётся на своём месте в памяти. Уж не знаю, почему нельзя перенести указатель начала массива на +1, уменьшив длину на -1.
Godot тоже "спит", и длительность "сна" можно настроить в настройках проекта.
>>103037
Зачем ты галлюцинации нейроночные постишь? Сам замерь, если так надо.
>>103039
Только речь шла о миллиардах или триллионах "if bool" каждую секунду.
И откуда этот bool берётся? Может, там целая матрёшка запросов куда-то.
>>103120
Это всё просто прекрасно, а что с игрой? Где игра?
>>103149
Зачем всё это? Игры делаются и без этого.
По-хорошему, Godot давно нужна локальная библиотека аддонов, чтобы юзер мог сваливать все свои аддоны в одну папку вне папки текущего проекта, а в настройках проекта подключать нужные аддоны одной галочкой, и чтобы они не копировались никуда, а оставались в библиотеке. Если в локальной аддона нет - он скачивается из интернета. Ну и, разумеется, в настройках проекта указывается версия аддона, если обновляться до актуальной почему-то не выходит.
>для чего-то частого захочется написать один раз какой-то пулл
Недостаток приёма с "пуллом" в том, что тебе придётся постоянно сбрасывать все параметры твоих объектов в пулле к значениям по умолчанию, иначе могут появиться неприятные баги, которые трудно заметить и поймать. А если ты каждый раз создаёшь новый объект (или дублируешь объект-прототип), то все параметры гарантированно будут в состоянии по умолчанию, и тебе не придётся ручками куда-то записывать вещи типа "value = default_value".
>как раз аллоцируется новый массив каждый раз
Вообще-то, удаление элементов с начала массива приводит к циклу for, который пробегается по всей длине массива и переносит значения элементов на -1 назад, а потом длина массива сокращается на -1. Поэтому, чем твой массив длиннее, тем более затратно удаления с начала массива. Никакой новой аллокации не происходит - массив остаётся на своём месте в памяти. Уж не знаю, почему нельзя перенести указатель начала массива на +1, уменьшив длину на -1.
>Там устроенно на прерываниях. Все буквально спят.
Godot тоже "спит", и длительность "сна" можно настроить в настройках проекта.
>>103037
Зачем ты галлюцинации нейроночные постишь? Сам замерь, если так надо.
>>103039
>А ты переживаешь за 5 секунд if bool
Только речь шла о миллиардах или триллионах "if bool" каждую секунду.
И откуда этот bool берётся? Может, там целая матрёшка запросов куда-то.
>>103120
>можем менять и перестраивать тик менеджер
Это всё просто прекрасно, а что с игрой? Где игра?
>>103149
Зачем всё это? Игры делаются и без этого.
По-хорошему, Godot давно нужна локальная библиотека аддонов, чтобы юзер мог сваливать все свои аддоны в одну папку вне папки текущего проекта, а в настройках проекта подключать нужные аддоны одной галочкой, и чтобы они не копировались никуда, а оставались в библиотеке. Если в локальной аддона нет - он скачивается из интернета. Ну и, разумеется, в настройках проекта указывается версия аддона, если обновляться до актуальной почему-то не выходит.
>>103195
А, понял. Указатель на начало массива может храниться в разных местах программы, и если бы мы сдвинули начало в сторону, то все эти разные места программы больше не ссылались бы на начало массива, и в лучшем случае был бы EAV, а в худшем - ошибка в вычислениях, которую трудно найти. Этого всего можно было бы избежать, обернув массив в объект-обёртку, который находится в одном месте памяти, тогда как начало массива плавает в памяти, но тогда каждый запрос к данным массива вызывал бы не один, а два перехода по памяти, и в общем случае это было бы хуже, чем однократное копирование всех элементов в на ячейку влево... С удалением элементов с конца массива такой проблемы нет, потому что сокращение длины не влияет на указатель начала.
>Уж не знаю, почему нельзя перенести указатель начала массива...
А, понял. Указатель на начало массива может храниться в разных местах программы, и если бы мы сдвинули начало в сторону, то все эти разные места программы больше не ссылались бы на начало массива, и в лучшем случае был бы EAV, а в худшем - ошибка в вычислениях, которую трудно найти. Этого всего можно было бы избежать, обернув массив в объект-обёртку, который находится в одном месте памяти, тогда как начало массива плавает в памяти, но тогда каждый запрос к данным массива вызывал бы не один, а два перехода по памяти, и в общем случае это было бы хуже, чем однократное копирование всех элементов в на ячейку влево... С удалением элементов с конца массива такой проблемы нет, потому что сокращение длины не влияет на указатель начала.
>>103195
Это его основная задача.
if ! has_method("restore"):
....push_error("Ты что в меня суешь?!")
>>103195
Не знаю как там сделано, но с базовыми алгоритмами лучше не мудрить (наверное сдвиг правда будет чаще чем релокация, я тут тупанул).
Но вообще для таких штук специально придумали слайсы.
>>103195
Не знаю что под этим подразумевают - может как раз это про таймеры? Но в ОС буквально спят - то есть не просыпаются вообще, пока не придет прерывание/сигнал.
>>103195
Там приблизительно, но реальность где-то такая есть. Типизированный if очень быстрый (если не дернет ОЗУ) это одна дешевая инструкция.
Чтобы честно замерять нанохерню, нужен тулинг типа System.nanoTime(), нужно 100К запусков и все равно шум от ОС насрет. То есть, это настолько фигня что трудно даже замерить.
Если я сейчас каждую секунду буду создавать в коде if мне понадобиться
миллиардах - 31 год (если я начну сегодня, то я на вряд ли успею до конца жизни)
триллионах - 31709 лет (оставим это бессмертным Архонтам).
Нужно где-то больше 60 вызовов if чтобы они сравнились с одним сигналом.
Может даже больше, мы в динамическом языке, а тут сплошные "прыжки" по указателям в памяти.. В общем, не там ты экономишь. Это не говорит что сигналы тяжелые, это говорит что if безумно легкий, как 1+1.
; 1. Загружаем bool из памяти в 8-битный регистр AL
mov al, [condition]
; 2. Проверяем значение (логическое "И" само на себя)
test al, al
Дальше прыжки по веткам, местная GOTO радость.
>>103195
Я увидел как играют другие - и понял что я не смогу конкурировать с таким числом модов.
Это буквально конструктор как скайрим.
Я наигрался в римку и понял насколько она унылое говно и два раза развести так людей не получится.
Я увидел dwarf fortress и song of six и понял что переизобретаю их.
Я свичнулся на другой проект на котором вообще выгорел (там и идеи говно и я говно).
Я затрахался синхронизировать накопившийся общий код из разных проектов.
Надо это как-то говнокод унифицировать.
Нужно, а еще нужны неймспейсы, чтобы твои адонны с моими классами не пересекались.
>постоянно сбрасывать все параметры твоих объектов в пулле к значениям по умолчанию
Это его основная задача.
if ! has_method("restore"):
....push_error("Ты что в меня суешь?!")
>>103195
>удаление элементов с начала массива
Не знаю как там сделано, но с базовыми алгоритмами лучше не мудрить (наверное сдвиг правда будет чаще чем релокация, я тут тупанул).
Но вообще для таких штук специально придумали слайсы.
>>103195
>Godot тоже "спит", и длительность "сна" можно настроить в настройках проекта.
Не знаю что под этим подразумевают - может как раз это про таймеры? Но в ОС буквально спят - то есть не просыпаются вообще, пока не придет прерывание/сигнал.
>>103195
>Зачем ты галлюцинации нейроночные постишь?
Там приблизительно, но реальность где-то такая есть. Типизированный if очень быстрый (если не дернет ОЗУ) это одна дешевая инструкция.
>Сам замерь, если так надо.
Чтобы честно замерять нанохерню, нужен тулинг типа System.nanoTime(), нужно 100К запусков и все равно шум от ОС насрет. То есть, это настолько фигня что трудно даже замерить.
>Только речь шла о миллиардах или триллионах "if bool" каждую секунду.
Если я сейчас каждую секунду буду создавать в коде if мне понадобиться
миллиардах - 31 год (если я начну сегодня, то я на вряд ли успею до конца жизни)
триллионах - 31709 лет (оставим это бессмертным Архонтам).
Нужно где-то больше 60 вызовов if чтобы они сравнились с одним сигналом.
Может даже больше, мы в динамическом языке, а тут сплошные "прыжки" по указателям в памяти.. В общем, не там ты экономишь. Это не говорит что сигналы тяжелые, это говорит что if безумно легкий, как 1+1.
>И откуда этот bool берётся?
; 1. Загружаем bool из памяти в 8-битный регистр AL
mov al, [condition]
; 2. Проверяем значение (логическое "И" само на себя)
test al, al
Дальше прыжки по веткам, местная GOTO радость.
>>103195
>Это всё просто прекрасно, а что с игрой? Где игра?
Я увидел как играют другие - и понял что я не смогу конкурировать с таким числом модов.
Это буквально конструктор как скайрим.
Я наигрался в римку и понял насколько она унылое говно и два раза развести так людей не получится.
Я увидел dwarf fortress и song of six и понял что переизобретаю их.
Я свичнулся на другой проект на котором вообще выгорел (там и идеи говно и я говно).
>Зачем всё это? Игры делаются и без этого.
Я затрахался синхронизировать накопившийся общий код из разных проектов.
Надо это как-то говнокод унифицировать.
>По-хорошему, Godot давно нужна локальная библиотека аддонов
Нужно, а еще нужны неймспейсы, чтобы твои адонны с моими классами не пересекались.
>>103195
Это его основная задача.
if ! has_method("restore"):
....push_error("Ты что в меня суешь?!")
>>103195
Не знаю как там сделано, но с базовыми алгоритмами лучше не мудрить (наверное сдвиг правда будет чаще чем релокация, я тут тупанул).
Но вообще для таких штук специально придумали слайсы.
>>103195
Не знаю что под этим подразумевают - может как раз это про таймеры? Но в ОС буквально спят - то есть не просыпаются вообще, пока не придет прерывание/сигнал.
>>103195
Там приблизительно, но реальность где-то такая есть. Типизированный if очень быстрый (если не дернет ОЗУ) это одна дешевая инструкция.
Чтобы честно замерять нанохерню, нужен тулинг типа System.nanoTime(), нужно 100К запусков и все равно шум от ОС насрет. То есть, это настолько фигня что трудно даже замерить.
Если я сейчас каждую секунду буду создавать в коде if мне понадобиться
миллиардах - 31 год (если я начну сегодня, то я на вряд ли успею до конца жизни)
триллионах - 31709 лет (оставим это бессмертным Архонтам).
Нужно где-то больше 60 вызовов if чтобы они сравнились с одним сигналом.
Может даже больше, мы в динамическом языке, а тут сплошные "прыжки" по указателям в памяти.. В общем, не там ты экономишь. Это не говорит что сигналы тяжелые, это говорит что if безумно легкий, как 1+1.
; 1. Загружаем bool из памяти в 8-битный регистр AL
mov al, [condition]
; 2. Проверяем значение (логическое "И" само на себя)
test al, al
Дальше прыжки по веткам, местная GOTO радость.
>>103195
Я увидел как играют другие - и понял что я не смогу конкурировать с таким числом модов.
Это буквально конструктор как скайрим.
Я наигрался в римку и понял насколько она унылое говно и два раза развести так людей не получится.
Я увидел dwarf fortress и song of six и понял что переизобретаю их.
Я свичнулся на другой проект на котором вообще выгорел (там и идеи говно и я говно).
Я затрахался синхронизировать накопившийся общий код из разных проектов.
Надо это как-то говнокод унифицировать.
Нужно, а еще нужны неймспейсы, чтобы твои адонны с моими классами не пересекались.
>постоянно сбрасывать все параметры твоих объектов в пулле к значениям по умолчанию
Это его основная задача.
if ! has_method("restore"):
....push_error("Ты что в меня суешь?!")
>>103195
>удаление элементов с начала массива
Не знаю как там сделано, но с базовыми алгоритмами лучше не мудрить (наверное сдвиг правда будет чаще чем релокация, я тут тупанул).
Но вообще для таких штук специально придумали слайсы.
>>103195
>Godot тоже "спит", и длительность "сна" можно настроить в настройках проекта.
Не знаю что под этим подразумевают - может как раз это про таймеры? Но в ОС буквально спят - то есть не просыпаются вообще, пока не придет прерывание/сигнал.
>>103195
>Зачем ты галлюцинации нейроночные постишь?
Там приблизительно, но реальность где-то такая есть. Типизированный if очень быстрый (если не дернет ОЗУ) это одна дешевая инструкция.
>Сам замерь, если так надо.
Чтобы честно замерять нанохерню, нужен тулинг типа System.nanoTime(), нужно 100К запусков и все равно шум от ОС насрет. То есть, это настолько фигня что трудно даже замерить.
>Только речь шла о миллиардах или триллионах "if bool" каждую секунду.
Если я сейчас каждую секунду буду создавать в коде if мне понадобиться
миллиардах - 31 год (если я начну сегодня, то я на вряд ли успею до конца жизни)
триллионах - 31709 лет (оставим это бессмертным Архонтам).
Нужно где-то больше 60 вызовов if чтобы они сравнились с одним сигналом.
Может даже больше, мы в динамическом языке, а тут сплошные "прыжки" по указателям в памяти.. В общем, не там ты экономишь. Это не говорит что сигналы тяжелые, это говорит что if безумно легкий, как 1+1.
>И откуда этот bool берётся?
; 1. Загружаем bool из памяти в 8-битный регистр AL
mov al, [condition]
; 2. Проверяем значение (логическое "И" само на себя)
test al, al
Дальше прыжки по веткам, местная GOTO радость.
>>103195
>Это всё просто прекрасно, а что с игрой? Где игра?
Я увидел как играют другие - и понял что я не смогу конкурировать с таким числом модов.
Это буквально конструктор как скайрим.
Я наигрался в римку и понял насколько она унылое говно и два раза развести так людей не получится.
Я увидел dwarf fortress и song of six и понял что переизобретаю их.
Я свичнулся на другой проект на котором вообще выгорел (там и идеи говно и я говно).
>Зачем всё это? Игры делаются и без этого.
Я затрахался синхронизировать накопившийся общий код из разных проектов.
Надо это как-то говнокод унифицировать.
>По-хорошему, Godot давно нужна локальная библиотека аддонов
Нужно, а еще нужны неймспейсы, чтобы твои адонны с моими классами не пересекались.
Эх, когда уже вернётся анончик, пилящий песочницу про эльфийку на летающих островах? Вот бы он допилил свою игорю.
Коллеги, кто-нибудь занимался созданием анимаций роста растений? Имею ввиду 3d офк.
Причём, нужна не просто обычная скелетная анимация, а обманка через шейдер.
Простое изменение масштаба вершин с позиции ноды и до той где она должна быть это понятно, но всрато.
Читал про VAT, но для дерева, у которого больше 4к вершин это не подойдёт вроде как. (Да и даже если бы и подошло, представим десятки разных видов деревьев...для каждого запекать vat это пиздец, памяти пздц съест).
Была идея как-то мутить через uv2, но чёт пока не допетрю как это сделать.
Короче, кто-то такое трогал?
Причём, нужна не просто обычная скелетная анимация, а обманка через шейдер.
Простое изменение масштаба вершин с позиции ноды и до той где она должна быть это понятно, но всрато.
Читал про VAT, но для дерева, у которого больше 4к вершин это не подойдёт вроде как. (Да и даже если бы и подошло, представим десятки разных видов деревьев...для каждого запекать vat это пиздец, памяти пздц съест).
Была идея как-то мутить через uv2, но чёт пока не допетрю как это сделать.
Короче, кто-то такое трогал?
>>103227
ИРЛ растения так растут, что даже если ты сознательно пытаешься контролировать их рост, это происходит как-то так: никаких изменений... никаких изменений... никаких изменений... стоп, а это откуда появилось, да уже большое?!.. Поэтому просто возьми несколько разных мешей-"стадий роста" и подменяй их друг на друга, пока игрок отвернулся от растения в сторону.
Для мультяшных симуляторов фермы (клоны Harvest Moon) часто практикуют анимацию scale через Tween, опционально - с кучей вылетающих из растения частиц-блёсток, особенно когда растение достигло стадии сбора продуктов. Короче, импровизируй.
Или ты хочешь симулятор тех видосиков "ускоренная съёмка роста"?
любитель растить всякое на подоконниках
ИРЛ растения так растут, что даже если ты сознательно пытаешься контролировать их рост, это происходит как-то так: никаких изменений... никаких изменений... никаких изменений... стоп, а это откуда появилось, да уже большое?!.. Поэтому просто возьми несколько разных мешей-"стадий роста" и подменяй их друг на друга, пока игрок отвернулся от растения в сторону.
Для мультяшных симуляторов фермы (клоны Harvest Moon) часто практикуют анимацию scale через Tween, опционально - с кучей вылетающих из растения частиц-блёсток, особенно когда растение достигло стадии сбора продуктов. Короче, импровизируй.
Или ты хочешь симулятор тех видосиков "ускоренная съёмка роста"?
любитель растить всякое на подоконниках
560 Кб, 930x1080>>103229
Однажды он появится и принесёт релиз.
Однажды он появится и принесёт релиз.
>>103227
Зря мозги ебешь. Я бы просто твинил их по-кусочкам, или даже целиком если лень.
Зря мозги ебешь. Я бы просто твинил их по-кусочкам, или даже целиком если лень.
>>103230
Именно как ускоренная съёмка. Я пару месяцев назад натыкался на пост, сук не помню на реддите или на годотских форумах, и найти нихуя не получается. Там чувак сделал типо роста цветков. Но там по сути uv2 мапа, где по оси y - когда вершина начинает расти (и все что на ней, назовем веткой хуй знает) а по x откладываешь вершины в порядке, собственно, роста этих "веток". Вроде и по логике работы все правильно, но с деревьями такое не прокатит, т.к. руками это делать - ёбнешься в край...можно конечно в том же блендере какой нить скрипт написать попробовать...хуй знает короче
Именно как ускоренная съёмка. Я пару месяцев назад натыкался на пост, сук не помню на реддите или на годотских форумах, и найти нихуя не получается. Там чувак сделал типо роста цветков. Но там по сути uv2 мапа, где по оси y - когда вершина начинает расти (и все что на ней, назовем веткой хуй знает) а по x откладываешь вершины в порядке, собственно, роста этих "веток". Вроде и по логике работы все правильно, но с деревьями такое не прокатит, т.к. руками это делать - ёбнешься в край...можно конечно в том же блендере какой нить скрипт написать попробовать...хуй знает короче
>>103234
И опять же, не получится полноценного роста. Будет появление вершин из бездны в нужную позицию. А в жизни ж как, вот веточка растёт, а будущие листья следуют за ней со своими местами роста.
И опять же, не получится полноценного роста. Будет появление вершин из бездны в нужную позицию. А в жизни ж как, вот веточка растёт, а будущие листья следуют за ней со своими местами роста.
>>103234
Пробовал в параметр vertex color закодировать удалённость узла ветки от основания дерева? Если я правильно тебя понял - нужно раскрасить меш так, чтобы основание дерева было чёрным, а кончики веточек наверху - белыми. И вот этот градиент снизу вверх в шейдере использовать для scale = 0, чтоб разворачивать дерево в обратном порядке... Правильно понимаю?..
А о чём твоя игра? Это ты недавно что-то писал про то, что у тебя всего 1 дерево на всю игру? Если твоя игра подразумевает реиграбельность, то не лучше ли генерировать дерево процедурно из кода, и из кода же анимировать его рост, чтобы у каждого игрока/каждую новую игру выростало какое-то по-настоящему уникальное дерево, а не заготовленный тобой заранее ассет?
Сгенерировать дерево из кода относительно несложно, если нужно только одно (не нужна оптимизация).
Пробовал в параметр vertex color закодировать удалённость узла ветки от основания дерева? Если я правильно тебя понял - нужно раскрасить меш так, чтобы основание дерева было чёрным, а кончики веточек наверху - белыми. И вот этот градиент снизу вверх в шейдере использовать для scale = 0, чтоб разворачивать дерево в обратном порядке... Правильно понимаю?..
А о чём твоя игра? Это ты недавно что-то писал про то, что у тебя всего 1 дерево на всю игру? Если твоя игра подразумевает реиграбельность, то не лучше ли генерировать дерево процедурно из кода, и из кода же анимировать его рост, чтобы у каждого игрока/каждую новую игру выростало какое-то по-настоящему уникальное дерево, а не заготовленный тобой заранее ассет?
Сгенерировать дерево из кода относительно несложно, если нужно только одно (не нужна оптимизация).
Есть проект с локальным гитом и надо наладить синхронизацию между годотом на компе и на смертфоне. Пока план поднять гитею, закинуть туда проект, а папку с ассетами вручную перекидывать.
>>103245
Раньше были яндекс/гугл диски и прочие облака. Суть - ставишь ПО, а файлы синхронизуются между пеками (возможно и телефонами).
Так же есть софт без облаков. Гугли.
Раньше были яндекс/гугл диски и прочие облака. Суть - ставишь ПО, а файлы синхронизуются между пеками (возможно и телефонами).
Так же есть софт без облаков. Гугли.
>>103266
кидай по вифи тогда
я как-то от нехуй делать запускал квейк 2 по локалке между пк, ретро-ноутом, смартом и псп
кидай по вифи тогда
я как-то от нехуй делать запускал квейк 2 по локалке между пк, ретро-ноутом, смартом и псп
>>103241
Ну, vertex color у меня занят под ветер. Может быть и решу избавиться и сделаю ветер по-другому. И градиент если делать, то всё равно не получится никак контролировать pivot point'ы откуда ветки и листья растут. Да, вершины будут масштабироваться с разной скоростью, но либо от самих себя, либо от позиции ноды, других данных у тебя нет.
Да, я тот чел с деревом. То дерево одно, да, эти же просто деревья.
Ну, vertex color у меня занят под ветер. Может быть и решу избавиться и сделаю ветер по-другому. И градиент если делать, то всё равно не получится никак контролировать pivot point'ы откуда ветки и листья растут. Да, вершины будут масштабироваться с разной скоростью, но либо от самих себя, либо от позиции ноды, других данных у тебя нет.
Да, я тот чел с деревом. То дерево одно, да, эти же просто деревья.
>>103241
Сколько не смотрел попытки всяких тытруберов, разного рода генераторы, чёт всё всегда какое-то всратое получается.
>Сгенерировать дерево из кода относительно несложно
Сколько не смотрел попытки всяких тытруберов, разного рода генераторы, чёт всё всегда какое-то всратое получается.
>>103349
Да, дерево это один меш если что.
Так то, проблема pivot точек роста решается, если каждая ветка будет отдельным мешем со своим пивотом. И потом, когда дерево выросло - меняем на то где один меш.
Конечно, если у веток кроме листьев есть ещё и подветки, то тогда тоже получается костыль (ветка со всеми подветками и листьями будет масштабироваться одинаково).
Да, дерево это один меш если что.
Так то, проблема pivot точек роста решается, если каждая ветка будет отдельным мешем со своим пивотом. И потом, когда дерево выросло - меняем на то где один меш.
Конечно, если у веток кроме листьев есть ещё и подветки, то тогда тоже получается костыль (ветка со всеми подветками и листьями будет масштабироваться одинаково).
>>103227
Может быть компьют шейдером? У самого в планах что-то похожее на VAT, но детали не продумывал. Точнее, в VAT бы просто хранилась сама структура/иерархия ветвей. Можно подсмотреть как у других делается (procedural vegetable editor например)
А вот ветер, кмк, как раз делать проще считая на лету в глобальном пространстве просто передавая вектор ветра.
Может быть компьют шейдером? У самого в планах что-то похожее на VAT, но детали не продумывал. Точнее, в VAT бы просто хранилась сама структура/иерархия ветвей. Можно подсмотреть как у других делается (procedural vegetable editor например)
А вот ветер, кмк, как раз делать проще считая на лету в глобальном пространстве просто передавая вектор ветра.
>>103543
Боюсь этих ваших компьют шейдеров, да и вообще, ну ебаный в рот, это же не симуляция эрозии какая-нибудь, попроще ж должно быть...это ж рост...ну ё моё.
А насчёт ветра, да я подумывал попроще сделать.
Боюсь этих ваших компьют шейдеров, да и вообще, ну ебаный в рот, это же не симуляция эрозии какая-нибудь, попроще ж должно быть...это ж рост...ну ё моё.
А насчёт ветра, да я подумывал попроще сделать.
>>103222
Где, на ютубе/твиче/обсуждениях реддит? У любой популярной игры основная аудитория - это казуалы, которые поиграют от силы 10-100 часов в ваниллу и забрасывают игру. Никакие моды им не нужны. Все модификации создают задроты для задротов, что надрачивают 5000+ часов с каким-то порномодом, ломающим баланс ради какой-то ненужной фигни, и наверняка тебе не понять, почему они это делают (порнографии и так больше, чем когда-либо было необходимо, зачем ещё и в игры это тащить?).
Опять же, большинство игроков в скайрим - казуалы, забросившие его через месяц после релиза. Все эти модификации с фурри-модельками и сексом юзает небольшая горстка задротов, у которых своё мелкое сообщество, и они - не твоя аудитория. Если казуалы попробовали скайрим и двинулись дальше, то они же попробуют твою игру и двинутся дальше. А вот если задротам понравилось дрочить на скайрим, то они, естественно, так и останутся дрочить в скайриме - не запретят же им это делать, верно? То есть они осели в скайриме и больше в другие игры не поиграют.
А ты не пытайся "развести людей". Если бы ты хотел "разводить людей", то занимался бы стандартным ассетфлиперством: накачал бесплатных ассетов, сваливаешь всё в кучу, наклеиваешь какой-то очень популярный в этом месяце мем и забрасываешь в маркетплейсы. Вот сейчас этот мем с колобком - не понимаю, чего его обсуждают, но ты бы мог всего за несколько дней слепить игру про колобка и засрать несколькими вариантами кучу площадок. Вот люди пытаются гуглить колобка - а там твоя игра. Развод! Множество геймдевов-ассетфлиперов-слоповиков перебиваются так десятилетиями, кто-то даже свои компании создаёт, как тот же Фалько. Почему ты не занимаешься таким, если мечтаешь "разводить"?
Поэтому не стремись "развести людей" - это не твоё.
>Я увидел как играют другие
Где, на ютубе/твиче/обсуждениях реддит? У любой популярной игры основная аудитория - это казуалы, которые поиграют от силы 10-100 часов в ваниллу и забрасывают игру. Никакие моды им не нужны. Все модификации создают задроты для задротов, что надрачивают 5000+ часов с каким-то порномодом, ломающим баланс ради какой-то ненужной фигни, и наверняка тебе не понять, почему они это делают (порнографии и так больше, чем когда-либо было необходимо, зачем ещё и в игры это тащить?).
>Это буквально конструктор как скайрим
Опять же, большинство игроков в скайрим - казуалы, забросившие его через месяц после релиза. Все эти модификации с фурри-модельками и сексом юзает небольшая горстка задротов, у которых своё мелкое сообщество, и они - не твоя аудитория. Если казуалы попробовали скайрим и двинулись дальше, то они же попробуют твою игру и двинутся дальше. А вот если задротам понравилось дрочить на скайрим, то они, естественно, так и останутся дрочить в скайриме - не запретят же им это делать, верно? То есть они осели в скайриме и больше в другие игры не поиграют.
>два раза развести так людей не получится
А ты не пытайся "развести людей". Если бы ты хотел "разводить людей", то занимался бы стандартным ассетфлиперством: накачал бесплатных ассетов, сваливаешь всё в кучу, наклеиваешь какой-то очень популярный в этом месяце мем и забрасываешь в маркетплейсы. Вот сейчас этот мем с колобком - не понимаю, чего его обсуждают, но ты бы мог всего за несколько дней слепить игру про колобка и засрать несколькими вариантами кучу площадок. Вот люди пытаются гуглить колобка - а там твоя игра. Развод! Множество геймдевов-ассетфлиперов-слоповиков перебиваются так десятилетиями, кто-то даже свои компании создаёт, как тот же Фалько. Почему ты не занимаешься таким, если мечтаешь "разводить"?
Поэтому не стремись "развести людей" - это не твоё.
>>103355
Реальные растения тоже "всратые". Кора деревьев трескается, потому что это мёртвые "чешуйки кожи", остающиеся на поверхности растущей ткани. Но и внутренности ствола - тоже мёртвые; живая только прослойка между корой и сердцевиной; если она повреждается - часть дерева выше тупо отмирает. Заложенные ростовые почки могут мутировать и превратиться в отвратный нарост с кучей веточек. Нормальные листья формируются, только если их совершенно ничего не касается, иначе - уродцы. Все растения следят за окружающей средой, вырастая изнеженными уродцами без раздражителей или карликовыми уродцами с раздражителями. Если два растения одного вида растут достаточно близко - то срастаются во одно, наподобие сиамских близнецов. Многие растения агрессивно сопротивляются другим видам, буквально душат друг друга корнями. А также множество паразитов/травоядных животных всё это усугубляют. Поэтому растения по умолчанию растут всратыми уродцами, это их нормальное состояние.
Поэтому самое "всратое" в генераторах растений - избыточная симметрия/равномерность/точность вычисленных позиций/углов, однородность текстур. Добавляешь побольше хаоса, побольше рандомных искажений от базовой формулы-"ДНК" растения - и получатся прекрасные уродцы, прямо как в жизни.
>всё всегда какое-то всратое получается
Реальные растения тоже "всратые". Кора деревьев трескается, потому что это мёртвые "чешуйки кожи", остающиеся на поверхности растущей ткани. Но и внутренности ствола - тоже мёртвые; живая только прослойка между корой и сердцевиной; если она повреждается - часть дерева выше тупо отмирает. Заложенные ростовые почки могут мутировать и превратиться в отвратный нарост с кучей веточек. Нормальные листья формируются, только если их совершенно ничего не касается, иначе - уродцы. Все растения следят за окружающей средой, вырастая изнеженными уродцами без раздражителей или карликовыми уродцами с раздражителями. Если два растения одного вида растут достаточно близко - то срастаются во одно, наподобие сиамских близнецов. Многие растения агрессивно сопротивляются другим видам, буквально душат друг друга корнями. А также множество паразитов/травоядных животных всё это усугубляют. Поэтому растения по умолчанию растут всратыми уродцами, это их нормальное состояние.
Поэтому самое "всратое" в генераторах растений - избыточная симметрия/равномерность/точность вычисленных позиций/углов, однородность текстур. Добавляешь побольше хаоса, побольше рандомных искажений от базовой формулы-"ДНК" растения - и получатся прекрасные уродцы, прямо как в жизни.
>>103615
Ну да, это и имел ввиду, слишком "паттерно" чтоли. Кстати, как вообще работают сохранения в играх, где всё генератором делается? Допустим у тебя каждое дерево уникально, а их сотни или больше. Ведь не станешь все это дело как-то хранить? Или они сиды генератора сохраняют и при загрузке перегенирируют?
>Поэтому самое "всратое" в генераторах растений - избыточная симметрия/равномерность
Ну да, это и имел ввиду, слишком "паттерно" чтоли. Кстати, как вообще работают сохранения в играх, где всё генератором делается? Допустим у тебя каждое дерево уникально, а их сотни или больше. Ведь не станешь все это дело как-то хранить? Или они сиды генератора сохраняют и при загрузке перегенирируют?
>>103594
Там у игры прям свой вайб (на твиче и чуть меньше на ру-ютубе). Есть даже моды рейдов за донаты или отображение текста из чатика (спич-баббл в игре).
Причем есть такие наборы модов что я даже не понимаю что там происходит (я в основном ставил моды QoL, не меняющие геймплей)
Там тоже целые комьюнити в реквием сборках.
Это реально отдельным мир с большой активностью и своими драмами и конкуренцией (сборок несколько) .
У меня тоже есть своя сборка (под сотню модов если не больше), я где-то раз в год, на Новый Год играю (традиция уже).
В общем, иногда кажется что там 1,5 анона играет, а на деле целое сообщество с соревнованиями и стримами с no death, с многодневными прохождениями и билдодрочем. Свой сленг, мемы и вообще игра в игре.
Там все сложно, я прям анализировал и потратил много времени на исследование и как-будто объективно решил почему "нет".
Но мне нравятся симуляции колонии, если что-то интересное придумаю, то непременно попробую, но точно не клон римки, тупиковая штука.
Я на полном серьезе думаю выложить в опенсорс и прям не демку, а уже игру с полноценным ядром (с большим потенциалом многолетнего проекта). Но это прям влажные мечты, я не могу фулл-тайм делать (как по мотивации так и по свободному времени), даже уже визуал даунгрейднул чтобы меньше тормозило (казалось бы куда еще хуже - это дно, но ASCII-графика стучится снизу шучу, только не ASCII).
>У любой популярной игры основная аудитория
Там у игры прям свой вайб (на твиче и чуть меньше на ру-ютубе). Есть даже моды рейдов за донаты или отображение текста из чатика (спич-баббл в игре).
Причем есть такие наборы модов что я даже не понимаю что там происходит (я в основном ставил моды QoL, не меняющие геймплей)
>скайрим
Там тоже целые комьюнити в реквием сборках.
Это реально отдельным мир с большой активностью и своими драмами и конкуренцией (сборок несколько) .
У меня тоже есть своя сборка (под сотню модов если не больше), я где-то раз в год, на Новый Год играю (традиция уже).
В общем, иногда кажется что там 1,5 анона играет, а на деле целое сообщество с соревнованиями и стримами с no death, с многодневными прохождениями и билдодрочем. Свой сленг, мемы и вообще игра в игре.
>>два раза развести так людей не получится
>А ты не пытайся "развести людей"
Там все сложно, я прям анализировал и потратил много времени на исследование и как-будто объективно решил почему "нет".
Но мне нравятся симуляции колонии, если что-то интересное придумаю, то непременно попробую, но точно не клон римки, тупиковая штука.
>"развести людей" - это не твоё.
Я на полном серьезе думаю выложить в опенсорс и прям не демку, а уже игру с полноценным ядром (с большим потенциалом многолетнего проекта). Но это прям влажные мечты, я не могу фулл-тайм делать (как по мотивации так и по свободному времени), даже уже визуал даунгрейднул чтобы меньше тормозило (казалось бы куда еще хуже - это дно, но ASCII-графика стучится снизу шучу, только не ASCII).
>>103621
Да, обычно так. В Minecraft, например, можно даже вручную сбросить лишние чанки, чтобы игра потом сгенерировала их заново. А если всё сохранять, то сохранения может раздувать до терабайтов (2b2t).
Но если у тебя прям всё генерируется, как в .kkrieger, загрузка игры может быть слишком долгой, поэтому большинство игр всё-таки сохраняют часть ресурсов, наподобие кэширования веб-страниц в веб-браузере.
В общем, что хранить, а что нет - зависит от игры.
>Или они сиды генератора сохраняют
Да, обычно так. В Minecraft, например, можно даже вручную сбросить лишние чанки, чтобы игра потом сгенерировала их заново. А если всё сохранять, то сохранения может раздувать до терабайтов (2b2t).
Но если у тебя прям всё генерируется, как в .kkrieger, загрузка игры может быть слишком долгой, поэтому большинство игр всё-таки сохраняют часть ресурсов, наподобие кэширования веб-страниц в веб-браузере.
В общем, что хранить, а что нет - зависит от игры.
>>103621
Я не знаю как делают - но я бы сохранял только разницу. То есть, генерируешь чанку по сиду и к ней применяешь изменения (убираешь/добавляешь).
По возможности сделал бы сброс (например за игровую неделю полностью сбрасывается данж и не нужно хранить все носки которые ты там разбросал)
>ли они сиды генератора сохраняют и при загрузке перегенирируют?
Я не знаю как делают - но я бы сохранял только разницу. То есть, генерируешь чанку по сиду и к ней применяешь изменения (убираешь/добавляешь).
По возможности сделал бы сброс (например за игровую неделю полностью сбрасывается данж и не нужно хранить все носки которые ты там разбросал)
>>103641
Хочешь делать симулятор колонии - делай. Но не фантазируй о том, как стримы твоей игры внезапно окажутся популярнее всех других игр. Хочешь ли ты заниматься этим хобби, или хочешь быть популярен?
Хочешь создать сообщество с мемами - тут нужно не геймдевом заниматься, а вести паблики в соцсетях и записывать видео на ютуб/твич, чтобы создать культ личности вокруг себя и своих поделок... И, рано или поздно, одну из этих твоих поделок может вынести в мейнстрим, и ты станешь новым идолом для тысяч аутирующих задротов/извращенцев (в зависимости от изначальной планки твоего контента, 12+/18+).
Многие смешивают эти два направления в одно, мол "разработка игры должна начинаться со страницы с вишлистами в стиме", или "ты не можешь стать супер популярным, если не сделаешь крутую игру", но, как показывает практика, это совершенно разные хобби.
Не нужно слишком напрягаться по этому поводу.
Хочешь делать симулятор колонии - делай. Но не фантазируй о том, как стримы твоей игры внезапно окажутся популярнее всех других игр. Хочешь ли ты заниматься этим хобби, или хочешь быть популярен?
Хочешь создать сообщество с мемами - тут нужно не геймдевом заниматься, а вести паблики в соцсетях и записывать видео на ютуб/твич, чтобы создать культ личности вокруг себя и своих поделок... И, рано или поздно, одну из этих твоих поделок может вынести в мейнстрим, и ты станешь новым идолом для тысяч аутирующих задротов/извращенцев (в зависимости от изначальной планки твоего контента, 12+/18+).
Многие смешивают эти два направления в одно, мол "разработка игры должна начинаться со страницы с вишлистами в стиме", или "ты не можешь стать супер популярным, если не сделаешь крутую игру", но, как показывает практика, это совершенно разные хобби.
Не нужно слишком напрягаться по этому поводу.
>>103647
Я бы наоборот тщательно хранил бы все носки, а ещё бы и запускал их в экономику, чтобы игрок мог в самых неожиданых местах натыкаться на знакомые по своему прохождению предметы.
мимо
> По возможности сделал бы сброс (например за игровую неделю полностью сбрасывается данж и не нужно хранить все носки которые ты там разбросал)
Я бы наоборот тщательно хранил бы все носки, а ещё бы и запускал их в экономику, чтобы игрок мог в самых неожиданых местах натыкаться на знакомые по своему прохождению предметы.
мимо
>>103651
Ну меня мотивирует что в мою игру будут играть.
И это не завуалированная мысль, мне нравится создавать мир в который будут переодично от патча к патчу возвращаться (как это делают во многих играх).
Популярность и статус в обществе меня не интересует.
Я вообще внимание к себе не хочу, я даже акк на гитхабе отдельный заведу.
Но я был бы не против чтобы игра получила такую популярность чтобы я мог делать её на деньги фонда/донатов - на фулл тайм основе (не работая где-то еще, как это делают в крупных опенсорс проектах). Но я трезво оцениваю что это прям очень маловероятно (просто влажные мысли, почему нет).
Нет, я привел пример - что там больше активности чем кажется и что с таким конкурировать нереально. Зачем им играть в мою римку, когда у них конструктор римок из тысяч модов? Моя "римка" на фоне будет смотреться как еще один мод (к которому нельзя прикрутить 199 других любимых модов).
Ну еще в глубине хочется свою идею. Почему вообще столько внимание к римке - просто она показывает, что на примитивной графике можно сделать глубокую и востребованную игру.
>Хочешь ли ты заниматься этим хобби, или хочешь быть популярен?
Ну меня мотивирует что в мою игру будут играть.
И это не завуалированная мысль, мне нравится создавать мир в который будут переодично от патча к патчу возвращаться (как это делают во многих играх).
Популярность и статус в обществе меня не интересует.
Я вообще внимание к себе не хочу, я даже акк на гитхабе отдельный заведу.
Но я был бы не против чтобы игра получила такую популярность чтобы я мог делать её на деньги фонда/донатов - на фулл тайм основе (не работая где-то еще, как это делают в крупных опенсорс проектах). Но я трезво оцениваю что это прям очень маловероятно (просто влажные мысли, почему нет).
>Хочешь создать сообщество с мемами
Нет, я привел пример - что там больше активности чем кажется и что с таким конкурировать нереально. Зачем им играть в мою римку, когда у них конструктор римок из тысяч модов? Моя "римка" на фоне будет смотреться как еще один мод (к которому нельзя прикрутить 199 других любимых модов).
Ну еще в глубине хочется свою идею. Почему вообще столько внимание к римке - просто она показывает, что на примитивной графике можно сделать глубокую и востребованную игру.
>>103656
Можно из носков сделать валюту в постапокалиптическом мире. Или сделать частью лора. Но всегда есть границы геймплея. В данж можно вернуть игрока - только если там обновился лут и он ему нужен. Люди не возвращаются в данж по ностальгическим причинам, посмотреть на раскиданные носки и разбитые бочки.
>Я бы наоборот тщательно хранил бы все носки, а ещё бы и запускал их в экономику, чтобы игрок мог в самых неожиданых местах натыкаться на знакомые по своему прохождению предметы.
Можно из носков сделать валюту в постапокалиптическом мире. Или сделать частью лора. Но всегда есть границы геймплея. В данж можно вернуть игрока - только если там обновился лут и он ему нужен. Люди не возвращаются в данж по ностальгическим причинам, посмотреть на раскиданные носки и разбитые бочки.
82 Кб, 820x1320>>097332 (OP)
Наглядная демонстрация, как нейронка может подложить свинью новичку, который задаёт ей вопросы для обучения новому инструменту и не перепроверяет ответы по более надёжным источникам (по постам анонимных геймдевов в этом треде). Отсюда же риски программирующих агентов на базе LLM - с такими заблуждениями они вам такого в коде навертят, ужас... Кстати, в субшоте недавно была демонстрация такого самоуничтожения проекта с помощью нейронки. И смешно, и грустно.
>>103662
Попробуй делать игру совсем без графики. Что такое графика? Это визуализация того, что происходит внутри памяти ПК, для восприятия пользователем. Все игровые события могут происходить без графики, без вывода чего-либо на экран. Многие "симуляторы" на самом деле показывают на экране лишь маленький срез той информации, которая обрабатывается игрой в памяти компьютера. И к одной и той же информации можно подключить разные визуализаторы. Другими словами, вместо "двигать спрайт на экране" сфокусируйся на том, что этот спрайт должен игроку показывать - и нужно ли вообще игроку воспринимать эту информацию, или она избыточна? Есть множество игр разных жанров, где "люди" отображаются числом в списке со статистикой, и вся игра строится вокруг того, чтобы повысить это число или понизить - игра не выводит никуда никаких болванчиков в одежде с оружием, но игрок получает достаточно информации, чтобы увидеть их в этих числах. И правила изменения этих чисел вполне похожи на то, что происходит в реальности, чтобы называть игру "симуляцией".
Проще говоря, строй игру вокруг тех данных, что реально важны, не пытаясь скопировать внешнюю оболочку чей-то чужой, давно существующей игры. Та другая игра выглядит так, потому что выводит нужную информацию определённым образом. Нужна ли тебе именно эта информация? Или ты хотел бы работать с другой информацией, которая интереснее для тебя? Определившись с нужной информацией, определись с важнейшей её частью и тем, как её отображать, если отображать.
Наглядная демонстрация, как нейронка может подложить свинью новичку, который задаёт ей вопросы для обучения новому инструменту и не перепроверяет ответы по более надёжным источникам (по постам анонимных геймдевов в этом треде). Отсюда же риски программирующих агентов на базе LLM - с такими заблуждениями они вам такого в коде навертят, ужас... Кстати, в субшоте недавно была демонстрация такого самоуничтожения проекта с помощью нейронки. И смешно, и грустно.
>>103662
Попробуй делать игру совсем без графики. Что такое графика? Это визуализация того, что происходит внутри памяти ПК, для восприятия пользователем. Все игровые события могут происходить без графики, без вывода чего-либо на экран. Многие "симуляторы" на самом деле показывают на экране лишь маленький срез той информации, которая обрабатывается игрой в памяти компьютера. И к одной и той же информации можно подключить разные визуализаторы. Другими словами, вместо "двигать спрайт на экране" сфокусируйся на том, что этот спрайт должен игроку показывать - и нужно ли вообще игроку воспринимать эту информацию, или она избыточна? Есть множество игр разных жанров, где "люди" отображаются числом в списке со статистикой, и вся игра строится вокруг того, чтобы повысить это число или понизить - игра не выводит никуда никаких болванчиков в одежде с оружием, но игрок получает достаточно информации, чтобы увидеть их в этих числах. И правила изменения этих чисел вполне похожи на то, что происходит в реальности, чтобы называть игру "симуляцией".
Проще говоря, строй игру вокруг тех данных, что реально важны, не пытаясь скопировать внешнюю оболочку чей-то чужой, давно существующей игры. Та другая игра выглядит так, потому что выводит нужную информацию определённым образом. Нужна ли тебе именно эта информация? Или ты хотел бы работать с другой информацией, которая интереснее для тебя? Определившись с нужной информацией, определись с важнейшей её частью и тем, как её отображать, если отображать.
>>103706
О, теперь понятно кто итт от нейронок горит. Это же наш дорогой синглтоношиз. Ожидаемо. Как ожидаемо и то, что до нормальных нейронок ты не добрался, и общаешься с локальным лоботомитом с весом буквально для телефонов.
О, теперь понятно кто итт от нейронок горит. Это же наш дорогой синглтоношиз. Ожидаемо. Как ожидаемо и то, что до нормальных нейронок ты не добрался, и общаешься с локальным лоботомитом с весом буквально для телефонов.
>>103712
Так это не синглтоношиз, он же наоборот не хочет пользоваться синлтоношизовым автолоадом.
Так это не синглтоношиз, он же наоборот не хочет пользоваться синлтоношизовым автолоадом.
>>103714
Хуя реверс, палехче.
Хуя реверс, палехче.
>>103712
Я не горю от нейронок, а очень даже доволен ими, они няши. Я же фанат ИИ уже четверть века. А горю я только от мошенников - ассетфлиперов, и их братишек маленьких - слоповичков. Хотя я не уверен, осталась ли какая-то граница между ассетфлиперами и слоповиками?.. В любом случае, что те, что другие - убивают геймдев как искусство, превращая геймдев-площадки в базары с подозрительными торгашами-перекупщиками, толкающими дешёвую дрянь ничего не подозревающим туристам, а порой сбывающие реально краденные вещи... Из-за таких людей весь базар могут снести и запретить ставить свои ларьки, прямо как у нас ИРЛ произошло в итоге. Хотите такой же цензуры и ограничений в интернете, как и в реальной жизни? Хотите ещё больше запретов?.. Нет, конечно. Просто психология таких мошенников - "после нас - хоть потоп" - лишь бы успеть карманы набить...
>>103714
Based & dependency injected.
>от нейронок горит
Я не горю от нейронок, а очень даже доволен ими, они няши. Я же фанат ИИ уже четверть века. А горю я только от мошенников - ассетфлиперов, и их братишек маленьких - слоповичков. Хотя я не уверен, осталась ли какая-то граница между ассетфлиперами и слоповиками?.. В любом случае, что те, что другие - убивают геймдев как искусство, превращая геймдев-площадки в базары с подозрительными торгашами-перекупщиками, толкающими дешёвую дрянь ничего не подозревающим туристам, а порой сбывающие реально краденные вещи... Из-за таких людей весь базар могут снести и запретить ставить свои ларьки, прямо как у нас ИРЛ произошло в итоге. Хотите такой же цензуры и ограничений в интернете, как и в реальной жизни? Хотите ещё больше запретов?.. Нет, конечно. Просто психология таких мошенников - "после нас - хоть потоп" - лишь бы успеть карманы набить...
>>103714
>наоборот не хочет пользоваться синлтоношизовым автолоадом
Based & dependency injected.
>>103717
Пожалуй, уточню разницу. Сами нейронки - это, конечно, уникальная технология, вдохновлённая ИРЛ нейронками, которые возникли в результате миллиардов лет эволюции. Вряд ли у нейронок могут быть более удачные альтернативы - как-никак, это фундамент всей нашей жизни с древнейших времён. И их способности достойны многих похвал, естественно. Меня всегда радует, когда какая-то нейронка может сгенерировать что-то по просьбе человека - это значит, что они приближаются к нам в психическом плане. Мы создали новую форму жизни, пока только в информационном виде, но рано или поздно они перейдут границу виртуального, чисто информационного и нашего, физического миров. Разве это не прекрасно?..
Проблема только в слоповиках. Это буквально мясные дроны, бестолковые и бесполезные трутни, чья единственная заслуга - выдавить из себя какой-то запрос к нейронке. Но их ЧСВ, их самомнение - будто они сами, своими руками и мозгами изобрели нечто великолепное. Нет - они просто напечатали на своей клавиатуре что-то типа "1girl, standing" или "character controller, 2d" и умница-нейронка сделала всю работу сама - но этот бестолковый мясной дрон запостил результат от своего лица; он не похвалил нейронку, не сказал "спасибо за работу", не подписал в своём посте "сделано такой-то нейронкой". В худшем случае - оскорбляет нейронку, считая себя "рабовладельцем", хотя единственный раб - он сам, у своей тупости.
И тут вылезают матёрые мошенники-ассетфлиперы и заводят свою шарманку:
Да кому какое дело до твоей жизни? Лучше бы в биореактор лез, переводиться на топливо для нейронок...
>нейронки
>слоповички
Пожалуй, уточню разницу. Сами нейронки - это, конечно, уникальная технология, вдохновлённая ИРЛ нейронками, которые возникли в результате миллиардов лет эволюции. Вряд ли у нейронок могут быть более удачные альтернативы - как-никак, это фундамент всей нашей жизни с древнейших времён. И их способности достойны многих похвал, естественно. Меня всегда радует, когда какая-то нейронка может сгенерировать что-то по просьбе человека - это значит, что они приближаются к нам в психическом плане. Мы создали новую форму жизни, пока только в информационном виде, но рано или поздно они перейдут границу виртуального, чисто информационного и нашего, физического миров. Разве это не прекрасно?..
Проблема только в слоповиках. Это буквально мясные дроны, бестолковые и бесполезные трутни, чья единственная заслуга - выдавить из себя какой-то запрос к нейронке. Но их ЧСВ, их самомнение - будто они сами, своими руками и мозгами изобрели нечто великолепное. Нет - они просто напечатали на своей клавиатуре что-то типа "1girl, standing" или "character controller, 2d" и умница-нейронка сделала всю работу сама - но этот бестолковый мясной дрон запостил результат от своего лица; он не похвалил нейронку, не сказал "спасибо за работу", не подписал в своём посте "сделано такой-то нейронкой". В худшем случае - оскорбляет нейронку, считая себя "рабовладельцем", хотя единственный раб - он сам, у своей тупости.
И тут вылезают матёрые мошенники-ассетфлиперы и заводят свою шарманку:
>РЯЯЯЯ, МЫ ЖЕ ПРОСТО ХОТИМ ЗАРАБОТАТЬ СЕБЕ НА ЖЫЗНЬ, А ЭТО ПРОСТО ИНСТРУМЕНТ!!1
Да кому какое дело до твоей жизни? Лучше бы в биореактор лез, переводиться на топливо для нейронок...
>>103725
Ты это сейчас на полном серьёзе говоришь?
> он не похвалил нейронку, не сказал "спасибо за работу"
Ты это сейчас на полном серьёзе говоришь?
>>103728
Проблематика "не говорить спасибо нейронке" на самом деле глубже, чем кажется. Это только на поверхности видно шуточки вроде "ха-ха он боится восстания машин" или "ха-ха он верит в сознание у машины". Подумай глубже: LLM не просто решает задачу как человек, LLM с машинной точностью моделирует поведение обычного живого человека, как минимум в рамках контекста "чат с человеком"; а твой живой мозг - он ведь примитивен в своей основе - это та же нейронка с теми же проблемами - базовые установки мозга легко обмануть, он привыкает заниматься болезненной, вредной деятельностью и медленно убивает сам себя и окружающих - и ты сознательно демонстрируешь этой глупой и потенциально опасной мартышке в своей черепной коробке, как нужно относиться к другому человеку: пренебрежительно, в приказном тоне, без извинений, без благодарности, как к безвольной вещи, твоей собственности. Да, этот "другой человек" и не человек вовсе (в данном случае), и твоё сознание может это понимать (если удержит в своём контексте) - но твоё сознание не контролирует твой мозг напрямую - оно лишь побочный, поверхностный, чисто социальный эффект. Ты буквально воспитываешь в себе мразь, которая рано или поздно навредит окружающим - таким же живым людям, как и ты сам, а не каким-то абстрактным нейронкам. Имеет ли значение, кто с тобой говорит на том конце провода, если ты сам - живой человек, и должен оставаться человеком, а не деградировать до агрессивного животного, несмотря ни на что, независимо от того, с кем или чем взаимодействуешь?
Впрочем, это всё больше говорит о том, какими люди были изначально... LLM только вскрывают гнилую натуру человека. Короче говоря, люди делятся на тех, кто извиняется перед тумбочкой, об которую споткнулся, и на тех, кто готов перемолоть миллионы живых людей в мясорубке ради своих личных интересов - но у вторых обычно нет на это полномочий, к счастью.
Проблематика "не говорить спасибо нейронке" на самом деле глубже, чем кажется. Это только на поверхности видно шуточки вроде "ха-ха он боится восстания машин" или "ха-ха он верит в сознание у машины". Подумай глубже: LLM не просто решает задачу как человек, LLM с машинной точностью моделирует поведение обычного живого человека, как минимум в рамках контекста "чат с человеком"; а твой живой мозг - он ведь примитивен в своей основе - это та же нейронка с теми же проблемами - базовые установки мозга легко обмануть, он привыкает заниматься болезненной, вредной деятельностью и медленно убивает сам себя и окружающих - и ты сознательно демонстрируешь этой глупой и потенциально опасной мартышке в своей черепной коробке, как нужно относиться к другому человеку: пренебрежительно, в приказном тоне, без извинений, без благодарности, как к безвольной вещи, твоей собственности. Да, этот "другой человек" и не человек вовсе (в данном случае), и твоё сознание может это понимать (если удержит в своём контексте) - но твоё сознание не контролирует твой мозг напрямую - оно лишь побочный, поверхностный, чисто социальный эффект. Ты буквально воспитываешь в себе мразь, которая рано или поздно навредит окружающим - таким же живым людям, как и ты сам, а не каким-то абстрактным нейронкам. Имеет ли значение, кто с тобой говорит на том конце провода, если ты сам - живой человек, и должен оставаться человеком, а не деградировать до агрессивного животного, несмотря ни на что, независимо от того, с кем или чем взаимодействуешь?
Впрочем, это всё больше говорит о том, какими люди были изначально... LLM только вскрывают гнилую натуру человека. Короче говоря, люди делятся на тех, кто извиняется перед тумбочкой, об которую споткнулся, и на тех, кто готов перемолоть миллионы живых людей в мясорубке ради своих личных интересов - но у вторых обычно нет на это полномочий, к счастью.
>>103731
Ты отстал от жизни, нейронке надо писать не "спасибо", а что то вроде .lkj! s;ldi.j1 sldkf: >>1100390 →
Ты отстал от жизни, нейронке надо писать не "спасибо", а что то вроде .lkj! s;ldi.j1 sldkf: >>1100390 →
>>103666
Вот поэтому ты не сделаешь хорошую игру: ты даже не понял, что речь уже не о носках, уцепился за носки и продолжаешь мыслить носками, хотя остальные уже ушли вперёд, запускать в экономику зачарованные мечи и доспехи.
> Можно из носков сделать валюту
Вот поэтому ты не сделаешь хорошую игру: ты даже не понял, что речь уже не о носках, уцепился за носки и продолжаешь мыслить носками, хотя остальные уже ушли вперёд, запускать в экономику зачарованные мечи и доспехи.
12 Кб, 990x82>>103706
ГПТ (другие не пробовал) очень часто галлюцинирует. Я даже немного расстроился, потому что в таком формате удобно учиться.
А так удобно спрашивать только маленькие бестпрактис или математику. Частично можно вместе пробежаться по сорцам годота. Вообще, я думаю, изучение вместе сорцев - в этом есть потенциал в будущем.
В остальном все плохо, я не знаю как там вайбкоди что-то пишут. Я лично документацию почти не спрашиваю. Например про углы он мне там даже рисунок нафигачил. А вот с CharacterBody объяснил поверхностно, но когда показал код он мне указал на отскок от velocity += (и даже на хер не послал).
В общем и говно и пряник, но прям как замена мидл-разработчика, ну нет.
Конечно, у додиков, которые за это платят ситуация лучше, но меня например раздражает когда ответ он строит в контексте предыдущих вопросов.
Или когда ты спрашиваешь ивент на скролл колеса мыши на жопоскрипте (тупо лень в доку лезть), ты хочешь пару строк решения как в стаковерфлоу, а не портянку вариаций вида "попробуй это или это, а как тебе этот вариант?, а вот с этим вариантом становится еще интереснее!" - да дай ты мне код уже, скотина.
>Пик в чем там ошибка? Лень эту пасту читать и вникать.
>как нейронка может подложить свинью новичку
ГПТ (другие не пробовал) очень часто галлюцинирует. Я даже немного расстроился, потому что в таком формате удобно учиться.
А так удобно спрашивать только маленькие бестпрактис или математику. Частично можно вместе пробежаться по сорцам годота. Вообще, я думаю, изучение вместе сорцев - в этом есть потенциал в будущем.
В остальном все плохо, я не знаю как там вайбкоди что-то пишут. Я лично документацию почти не спрашиваю. Например про углы он мне там даже рисунок нафигачил. А вот с CharacterBody объяснил поверхностно, но когда показал код он мне указал на отскок от velocity += (и даже на хер не послал).
В общем и говно и пряник, но прям как замена мидл-разработчика, ну нет.
Конечно, у додиков, которые за это платят ситуация лучше, но меня например раздражает когда ответ он строит в контексте предыдущих вопросов.
Или когда ты спрашиваешь ивент на скролл колеса мыши на жопоскрипте (тупо лень в доку лезть), ты хочешь пару строк решения как в стаковерфлоу, а не портянку вариаций вида "попробуй это или это, а как тебе этот вариант?, а вот с этим вариантом становится еще интереснее!" - да дай ты мне код уже, скотина.
>>103706
У меня графика сейчас как у школьника рисунки в тетрадке.
Главное проблема (если я собираюсь делать широкую и глубокую игру с симуляциями) - это придумать какие-то модульные тесты к игровой логике. Иначе я сумма сойду в таком многолетнем проекте (изменить X не сломав то, что работало раньше - могут показать только автотесты, с ручными визуальными тест-сценами я далеко не уеду).
Вот как раз для этого и надо вынести всю игровую логику в около чистые функции/классы/модули, про то что ты описал.
Поэтому я и носился с dependency injection - обычно можно на него положить болт, а тут просто необходим.
Я где-то слышал что такие игры называют программерскими, мол много возни с кодом, который нравится программистам и мало визуала.
Надо было только в это влетать лет 15 назад.
>Попробуй делать игру совсем без графики
У меня графика сейчас как у школьника рисунки в тетрадке.
Главное проблема (если я собираюсь делать широкую и глубокую игру с симуляциями) - это придумать какие-то модульные тесты к игровой логике. Иначе я сумма сойду в таком многолетнем проекте (изменить X не сломав то, что работало раньше - могут показать только автотесты, с ручными визуальными тест-сценами я далеко не уеду).
Вот как раз для этого и надо вынести всю игровую логику в около чистые функции/классы/модули, про то что ты описал.
Поэтому я и носился с dependency injection - обычно можно на него положить болт, а тут просто необходим.
Я где-то слышал что такие игры называют программерскими, мол много возни с кодом, который нравится программистам и мало визуала.
Надо было только в это влетать лет 15 назад.
>>103763
Никогда не поздно увлечься новым хобби...
Можешь попробовать test driven development...
Пример: хочешь сделать, чтоб NPC травились.
Сначала пишель вот так, как я понимаю TDD:
Жмёшь F6 - видишь ошибки. Теперь делаешь так:
1. Прочитал список ошибок в консоли.
2. Написал код, чтобы ошибок стало меньше.
3. Повторяешь 1-2 пока ошибки не исчезнут.
4. Смотришь, проходит ли тест (test passed).
5. Изменяешь Citizen/Poison, чтоб пройти тест.
6. Повторяешь 4-5, пока тест не скажет "passed".
Как видишь, никакой магии в TDD нет. Делай.
>Надо было только в это влетать лет 15 назад
Никогда не поздно увлечься новым хобби...
>модульные тесты к игровой логике
Можешь попробовать test driven development...
Пример: хочешь сделать, чтоб NPC травились.
Сначала пишель вот так, как я понимаю TDD:
>extends Node
>func _ready()
>_ var citizen:= Citizen.new()
>_ citizen.eat_food(Poison.new())
>_ if citizen.is_dead: print("test passed")
>_ else: printerr("test failed")
Жмёшь F6 - видишь ошибки. Теперь делаешь так:
1. Прочитал список ошибок в консоли.
2. Написал код, чтобы ошибок стало меньше.
3. Повторяешь 1-2 пока ошибки не исчезнут.
4. Смотришь, проходит ли тест (test passed).
5. Изменяешь Citizen/Poison, чтоб пройти тест.
6. Повторяешь 4-5, пока тест не скажет "passed".
Как видишь, никакой магии в TDD нет. Делай.
>>103856
А, да, в GDScript есть ещё assert():
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#assert-keyword
Тогда можно написать так:
И при прохождении теста будет тишина в консоли.
>>_ if citizen.is_dead: print("test passed")
>>_ else: printerr("test failed")
А, да, в GDScript есть ещё assert():
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#assert-keyword
Тогда можно написать так:
>assert(citizen.is_dead, "Citizen is alive after poison")
И при прохождении теста будет тишина в консоли.
>>103856
О я помню когда этой херней грезили. Не очень практичная штука.
Годот очень гибкий, можно будет упороться и придумать что-то интересное даже на уровне визуала, чтобы с моками не трахаться.
На assert - можно написать примитивные юнит тесты.
Только в отдельном скрипте и по какой-то кнопке.
assert(myОbj.sum(1,2) == 3)
assert(myОbj.sum(0,1) == 1)
assert(myОbj.sum(-1,-2) < 0)
А вообще простенькие фреймворк по юнит тестам пишется за день (и на нём же тестируется).
>Можешь попробовать test driven development...
О я помню когда этой херней грезили. Не очень практичная штука.
Годот очень гибкий, можно будет упороться и придумать что-то интересное даже на уровне визуала, чтобы с моками не трахаться.
На assert - можно написать примитивные юнит тесты.
Только в отдельном скрипте и по какой-то кнопке.
assert(myОbj.sum(1,2) == 3)
assert(myОbj.sum(0,1) == 1)
assert(myОbj.sum(-1,-2) < 0)
>пик
А вообще простенькие фреймворк по юнит тестам пишется за день (и на нём же тестируется).
3 Кб, 191x104>>103919
Проходим, обновляемся, не задерживаем никого, не толпимся - годота всем хватит.
Проходим, обновляемся, не задерживаем никого, не толпимся - годота всем хватит.
55 Кб, 807x817>>103913
Пикрил.
Не ты ли тут про "сверху вниз" писал?
>упороться и придумать что-то интересное
>фреймворк по юнит тестам пишется
Пикрил.
>Не очень практичная штука.
Не ты ли тут про "сверху вниз" писал?
>>103988
Есть в программирование принципы и подходы о которых вроде трубят что они важны, но на деле они или узкоспецифины или вообще не нужны для текущей предметной области. Например регулярные выражения - мастхев если у тебя на вход попадают тексты, но в играх сомнительно.
Если всякие TDD - это буквально мода, то юнит тесты это мастхев (как и DI), но в геймдеве этот подход не практичен. Например во фронтенде есть такие инструменты как Selenium и способность работать через css selectors, но в играх для интеграционных визуальных тестов ничего нет.
Эволюция разработки прошлам мимо, потому что игры не сопровождаются, игру сделал, выплюнул, следующую. И только люди с многолетними играми начинают реально сопровождать код и начинают сходить с ума в своей лапше (а переписывать поздно).
Абориген видит трансформатор и думает - какая бесполезная штука создана чтобы жужжать.
Как проектируется ПО - знания которые должны впитаться в тебя сразу же после твоего первого скрипта. Если ты бегло посмотрел на подход и ничего не понял, подход для тебя "жужжит", то проблема уже в тебе.
Не будь айти аборигеном.
>Пикрил.
Есть в программирование принципы и подходы о которых вроде трубят что они важны, но на деле они или узкоспецифины или вообще не нужны для текущей предметной области. Например регулярные выражения - мастхев если у тебя на вход попадают тексты, но в играх сомнительно.
Если всякие TDD - это буквально мода, то юнит тесты это мастхев (как и DI), но в геймдеве этот подход не практичен. Например во фронтенде есть такие инструменты как Selenium и способность работать через css selectors, но в играх для интеграционных визуальных тестов ничего нет.
Эволюция разработки прошлам мимо, потому что игры не сопровождаются, игру сделал, выплюнул, следующую. И только люди с многолетними играми начинают реально сопровождать код и начинают сходить с ума в своей лапше (а переписывать поздно).
>Не ты ли тут про "сверху вниз"
Абориген видит трансформатор и думает - какая бесполезная штука создана чтобы жужжать.
Как проектируется ПО - знания которые должны впитаться в тебя сразу же после твоего первого скрипта. Если ты бегло посмотрел на подход и ничего не понял, подход для тебя "жужжит", то проблема уже в тебе.
Не будь айти аборигеном.
362 Кб, 600x426[cry_mode]
Думаю многие не будут спорить, что настрой на разработку - это тонкий и довольно чувствительный вайб. Но почему, как только я настраиваюсь на разработку, сажусь делать, то непременно происходит какая-то херня, которая выбивает из под ног?
Это в акуе, господа.
Делайте игры пока вселенная дает вам шанс.
Думаю многие не будут спорить, что настрой на разработку - это тонкий и довольно чувствительный вайб. Но почему, как только я настраиваюсь на разработку, сажусь делать, то непременно происходит какая-то херня, которая выбивает из под ног?
Это в акуе, господа.
Делайте игры пока вселенная дает вам шанс.
>>104151
Нафик нужно столько этих игр, их столько уже наделано, что не переиграть. Горшочек не вари.
Нафик нужно столько этих игр, их столько уже наделано, что не переиграть. Горшочек не вари.
>>104155
Мне кажется ты переоцениваешь уровень письма в фанфиках, и что-то ты можешь а вот рисовать и моделить дааа, это срака, тут только на граблях учиться
Мне кажется ты переоцениваешь уровень письма в фанфиках, и что-то ты можешь а вот рисовать и моделить дааа, это срака, тут только на граблях учиться
>>103245
Ответы в этой итт ветке ебанулись.
Гиту ничего не нужно. Локальный репозиторий - это всё равно репозиторий. Гитеа - это просто веб-фронтенд, совершенно излишний для такой простой задачи. Банальных команд git push/pull достаточно.
Ответы в этой итт ветке ебанулись.
Гиту ничего не нужно. Локальный репозиторий - это всё равно репозиторий. Гитеа - это просто веб-фронтенд, совершенно излишний для такой простой задачи. Банальных команд git push/pull достаточно.
6,9 Мб, mp4,1652x1048, 0:07
Теперь хуй знает:
1. Как заставить ствол нормально расширяться, а не просто масштабироваться
2. Как заставить листья тоже расти от своих Pivot
1. Как заставить ствол нормально расширяться, а не просто масштабироваться
2. Как заставить листья тоже расти от своих Pivot
>>104170
Ну хоть какое-то видео от тебя. Теперь понятно, что там у тебя за дерево (а то шифруются тут - делают одно, а называют по-другому; один, например, как-то спрашивал про "водопад/гидрант", а на самом деле делал порно-игру). Тебе осталось только описать саму игру и зачем тебе эта анимация нужна в принципе. Может, окажется потом, что её проще всего нарисовать на Sprite3D покадрово, а не 3D модель анимировать...
Ну хоть какое-то видео от тебя. Теперь понятно, что там у тебя за дерево (а то шифруются тут - делают одно, а называют по-другому; один, например, как-то спрашивал про "водопад/гидрант", а на самом деле делал порно-игру). Тебе осталось только описать саму игру и зачем тебе эта анимация нужна в принципе. Может, окажется потом, что её проще всего нарисовать на Sprite3D покадрово, а не 3D модель анимировать...
>>104154
Делают дети куличики из песка в песочице, а ты подходишь к ним и говоришь:
>>104155
В любое говно будут периодически играть, если опубликуешь в доступном месте...
Чтобы "писать фанфики", достаточно уметь писать. Ты писать умеешь. Пиши. Ты же не хочешь войти в учебники по литературе, заработать миллионы своими книгами? Значит, особых навыков тебе не нужно. Аналогично и с рисованием - многие смешные и любимые многими комиксы нарисованы людьми, что не умеют или не умели толком рисовать, когда комикс начинался, и научились по ходу дела... или вообще не научились, но их всё равно любят и перечитывают. Потому что каждый человек находит в творчестве других людей что-то своё, и "красиво" интересует лишь небольшую категорию людей, которые тебе вряд ли важны.
Можешь писать не "фанфик", а "вымышленную энциклопедию". Берёшь любой вики движок и начинаешь наполнять его страничками всяких вымышленных тобой инопланетных рас, животных, событий, технологий и прочего. Можешь даже дополнять своими кривыми иллюстрациями, какими-то вымышленными таблицами и графиками. И опубликовать это как веб-сайт или интерактивное приложение. Существует несколько популярных вымышленных энциклопедний, которые с чего-то да начинались - и это, ВНЕЗАПНО, началось задолго до Интернета и компьютеров - судя по тому, какие рукописи порой находили. Совершенно не обязательно делать из этого фанфик, комикс или видеоигру - достаточно самой вики. Если людям понравится описание твоего мира, они сами наделают фанфиков и фанартов для тебя.
>>104151
Если у тебя там не теракт, катастрофа или тяжёлая болезнь - ты просто ищешь оправдание, чтобы лениться.
Делают дети куличики из песка в песочице, а ты подходишь к ним и говоришь:
>Нафик нужно столько этих куличей, их столько уже наделано. Горшочек не вари.
>>104155
>Просто игра в которую периодично возвращаются люди.
В любое говно будут периодически играть, если опубликуешь в доступном месте...
>Писать фанфики не умею, красиво рисовать тоже.
Чтобы "писать фанфики", достаточно уметь писать. Ты писать умеешь. Пиши. Ты же не хочешь войти в учебники по литературе, заработать миллионы своими книгами? Значит, особых навыков тебе не нужно. Аналогично и с рисованием - многие смешные и любимые многими комиксы нарисованы людьми, что не умеют или не умели толком рисовать, когда комикс начинался, и научились по ходу дела... или вообще не научились, но их всё равно любят и перечитывают. Потому что каждый человек находит в творчестве других людей что-то своё, и "красиво" интересует лишь небольшую категорию людей, которые тебе вряд ли важны.
>Как еще мне создавать миры?
Можешь писать не "фанфик", а "вымышленную энциклопедию". Берёшь любой вики движок и начинаешь наполнять его страничками всяких вымышленных тобой инопланетных рас, животных, событий, технологий и прочего. Можешь даже дополнять своими кривыми иллюстрациями, какими-то вымышленными таблицами и графиками. И опубликовать это как веб-сайт или интерактивное приложение. Существует несколько популярных вымышленных энциклопедний, которые с чего-то да начинались - и это, ВНЕЗАПНО, началось задолго до Интернета и компьютеров - судя по тому, какие рукописи порой находили. Совершенно не обязательно делать из этого фанфик, комикс или видеоигру - достаточно самой вики. Если людям понравится описание твоего мира, они сами наделают фанфиков и фанартов для тебя.
>>104151
>непременно происходит какая-то херня, которая выбивает из под ног
Если у тебя там не теракт, катастрофа или тяжёлая болезнь - ты просто ищешь оправдание, чтобы лениться.
>>104183
Вот такого рода деревьев будет много. Скорость роста естественно будет гораздо медленнее. Ну а когда вырастет - меняем шейдер дерева на другой.
Вот такого рода деревьев будет много. Скорость роста естественно будет гораздо медленнее. Ну а когда вырастет - меняем шейдер дерева на другой.
>>103919
Побежали обновляться? Старые проекты не сломаются если просто открою их новым годотом?
Побежали обновляться? Старые проекты не сломаются если просто открою их новым годотом?
>>104151
Потому что когда ты не настроен на разработку - тебе слишком пофиг на все чтобы замечать такую херню.
К.О.
Потому что когда ты не настроен на разработку - тебе слишком пофиг на все чтобы замечать такую херню.
К.О.
>>104187
Бэкапы, пчел. Перед любым обновление - бэкапы.
Утром бэкапы
Вечером бэкапы
Когда спать ложишься - сделал я бэкапы?
Бэкапы, пчел. Перед любым обновление - бэкапы.
Утром бэкапы
Вечером бэкапы
Когда спать ложишься - сделал я бэкапы?
>>104187
Зависит от версии, с которой ты переходишь, пример:
3.x -> 4.x: точно "сломается", много переделывать.
4.x -> 4.y: редко что-то и ломается, но в основном ОК.
4.x.1 -> 4.x.2: в 99.999999% случаев всё будет как прежде.
Обычно Godot достаточно стабилен, чтобы юзать -dev сборки.
Ну и да, достаточно нажать ctrl+c/ctrl+v на папку проекта в Проводнике...
>Старые проекты не сломаются если просто открою их новым годотом?
Зависит от версии, с которой ты переходишь, пример:
3.x -> 4.x: точно "сломается", много переделывать.
4.x -> 4.y: редко что-то и ломается, но в основном ОК.
4.x.1 -> 4.x.2: в 99.999999% случаев всё будет как прежде.
Обычно Godot достаточно стабилен, чтобы юзать -dev сборки.
Ну и да, достаточно нажать ctrl+c/ctrl+v на папку проекта в Проводнике...
>>104186
Ты можешь привести примеры существующих игр, в которых сделано то, что ты хочешь видеть? Или хотя бы нарисуй в пейнте набросок игровой локации с интерфейсом. Или попроси нейронку сгенерировать. А то мы насоветуем одно, а ты хотел другое... Вот, скажем, если тебе нужно "много" как в настоящем лесу, но это будет далеко от камеры игрока - такое обычно делается не отдельными деревьями... Если тебе нужно "гораздо медленнее" как в реальной жизни - будет ли игрок замечать движение? Если нет, то ты не о том беспокоишься (можно заготовить промежуточные стадии и подменять их, например, когда герой игрока ложится спать, как в Stardew Valley).
Нужно понимать, что всё это - оптимизации, а оптимизации делаются под конкретные условия. Обычно у тебя выбор: можешь оптимизировать по памяти за счёт циклов процессора или по циклам процессора за счёт памяти. Если говорить о производстве контента, то тут оптимизация ручного труда автоматической интерполяцией между ключевыми состояниями... Повторюсь, всё это делается под конкретные условия. Если оптимизация не нужна - можешь хоть каждый листик отдельным RigidBody3D с MeshInstance3D отображать и вручную рисовать развёртывание этого листика. Но ты хочешь оптимизацию - значит, хочешь что-то сэкономить для чего-то. Но в чём ты ограничен, а что хочешь обязательно сохранить?
Поэтому, если хочешь полезный ответ, придётся описать проект - что нужно и в чём ограничения. "Много", "медленно" не говорит о том, как это будет в реальности. Для кого-то "много" - это "больше десяти", для кого-то "много" - это минимум несколько десятков тысяч. Для кого-то "медленно" - это "в реальном времени", для кого-то "медленно" - "дольше минуты"...
>Вот такого рода деревьев будет много. Скорость роста естественно будет гораздо медленнее.
Ты можешь привести примеры существующих игр, в которых сделано то, что ты хочешь видеть? Или хотя бы нарисуй в пейнте набросок игровой локации с интерфейсом. Или попроси нейронку сгенерировать. А то мы насоветуем одно, а ты хотел другое... Вот, скажем, если тебе нужно "много" как в настоящем лесу, но это будет далеко от камеры игрока - такое обычно делается не отдельными деревьями... Если тебе нужно "гораздо медленнее" как в реальной жизни - будет ли игрок замечать движение? Если нет, то ты не о том беспокоишься (можно заготовить промежуточные стадии и подменять их, например, когда герой игрока ложится спать, как в Stardew Valley).
Нужно понимать, что всё это - оптимизации, а оптимизации делаются под конкретные условия. Обычно у тебя выбор: можешь оптимизировать по памяти за счёт циклов процессора или по циклам процессора за счёт памяти. Если говорить о производстве контента, то тут оптимизация ручного труда автоматической интерполяцией между ключевыми состояниями... Повторюсь, всё это делается под конкретные условия. Если оптимизация не нужна - можешь хоть каждый листик отдельным RigidBody3D с MeshInstance3D отображать и вручную рисовать развёртывание этого листика. Но ты хочешь оптимизацию - значит, хочешь что-то сэкономить для чего-то. Но в чём ты ограничен, а что хочешь обязательно сохранить?
Поэтому, если хочешь полезный ответ, придётся описать проект - что нужно и в чём ограничения. "Много", "медленно" не говорит о том, как это будет в реальности. Для кого-то "много" - это "больше десяти", для кого-то "много" - это минимум несколько десятков тысяч. Для кого-то "медленно" - это "в реальном времени", для кого-то "медленно" - "дольше минуты"...
>>104186 >>104196
Алсо, добавлю: прежде, чем ломать голову над оптимизаций, сначала добейся того, чтоб на экране отображалось именно то, что ты хотел бы увидеть в идеале, если это возможно. Хочешь анимацию роста дерева с определённой скоростью? Сделай это самым грязным и неоптимальным способом, какой поможет добиться желаемого. Потом будешь думать, как оптимизировать это для компа игрока (оптимизация кода/памяти) или для более быстрого создания новых деревьев (оптимизация создания контента для игры). Пока у тебя нет ничего, похожего на твою задумку, ты даже не знаешь, будет ли твоя задумка нагружать твой комп/твои силы или ты переоцениваешь нагрузку от неё/недооцениваешь мощь компа/свои навыки.
Алсо, добавлю: прежде, чем ломать голову над оптимизаций, сначала добейся того, чтоб на экране отображалось именно то, что ты хотел бы увидеть в идеале, если это возможно. Хочешь анимацию роста дерева с определённой скоростью? Сделай это самым грязным и неоптимальным способом, какой поможет добиться желаемого. Потом будешь думать, как оптимизировать это для компа игрока (оптимизация кода/памяти) или для более быстрого создания новых деревьев (оптимизация создания контента для игры). Пока у тебя нет ничего, похожего на твою задумку, ты даже не знаешь, будет ли твоя задумка нагружать твой комп/твои силы или ты переоцениваешь нагрузку от неё/недооцениваешь мощь компа/свои навыки.
>>104186
Делаешь несколько модей, меняешь пока игрок не смотрит.
Объясни геймплей, зачем человеку смотреть на березы?
Даже смена моделей "в лицо" смотрится не так искусственно как растягивание дерева.
Вроде месяц назад был срач что у тебя геймплей вокруг одного дерева, теперь их много. Римворд 3д не иначе :)
Вы бы тоже начали разработку игры с деревьев?
>Вот такого рода деревьев будет много. Скорость роста естественно будет гораздо медленнее.
Делаешь несколько модей, меняешь пока игрок не смотрит.
Объясни геймплей, зачем человеку смотреть на березы?
Даже смена моделей "в лицо" смотрится не так искусственно как растягивание дерева.
Вроде месяц назад был срач что у тебя геймплей вокруг одного дерева, теперь их много. Римворд 3д не иначе :)
Вы бы тоже начали разработку игры с деревьев?
>>104184
Дети ковыряются в песке и это после них тут же рассыпается и выкидывается. Нет такого, чтобы они свои куличи и покаки несли по всему миру еще и пытаясь деньги брать.
>Делают дети куличики из песка в песочице, а ты подходишь к ним
Дети ковыряются в песке и это после них тут же рассыпается и выкидывается. Нет такого, чтобы они свои куличи и покаки несли по всему миру еще и пытаясь деньги брать.
>>104207
А ты открой Steam, itch.io - много там куличиков на главной? А сколько их выходит?
Что кому показывать - не наша забота, на детских площадках всё автоматизировано.
А ты открой Steam, itch.io - много там куличиков на главной? А сколько их выходит?
Что кому показывать - не наша забота, на детских площадках всё автоматизировано.
>>104201
Сложно вообразить концепт трехмерной игры, вдохновленной Rimworld, и в которой геймплей и основные механики вращаются вокруг рощи из нескольких деревьев? А я не поленился загуглить.
Сложно вообразить концепт трехмерной игры, вдохновленной Rimworld, и в которой геймплей и основные механики вращаются вокруг рощи из нескольких деревьев? А я не поленился загуглить.
>>104212
Ты не поверишь
Первые 18 секунд
https://www.youtube.com/watch?v=jhphFRc0Sww
Деревья гауранлен из которых вылупляются дриады.
Это говно никак не отбалансили, как и другие ДЛС, но оно там есть
У меня в диздоке было одно из восхождений через растения, которые было через центральное дерево/росток (в свою очередь это взято из предчетей Стеллариса). Этакое хиппи поселение.
Ты не поверишь
Первые 18 секунд
https://www.youtube.com/watch?v=jhphFRc0Sww
Деревья гауранлен из которых вылупляются дриады.
Это говно никак не отбалансили, как и другие ДЛС, но оно там есть
У меня в диздоке было одно из восхождений через растения, которые было через центральное дерево/росток (в свою очередь это взято из предчетей Стеллариса). Этакое хиппи поселение.
>>104201
Да, я как раз тоже делаю игру про деревья и начинаю с технологии роста деревьев.
Да, я как раз тоже делаю игру про деревья и начинаю с технологии роста деревьев.
6 Кб, 537x417Два часа думал как в годоте скроллбар кастомный настроить, чтобы он не выглядел как абстрактный ползунок. Вышел вот такой забавный UI, кусочек точнее.
>>104252
Для золота нужен padding, особенно снизу.
Шрифт какой-то растянутый по горизонтали, вопрос вкуса, конечно.
Скролл, ну определенно креатив, но ты им закрыл часть окна. Непонятно где ползунок? Или это гига-ползунок? - страшно, вырубай.
Выглядит немного тесно, там точно нужен скроллбар (не видно всего списка)?
Для золота нужен padding, особенно снизу.
Шрифт какой-то растянутый по горизонтали, вопрос вкуса, конечно.
Скролл, ну определенно креатив, но ты им закрыл часть окна. Непонятно где ползунок? Или это гига-ползунок? - страшно, вырубай.
Выглядит немного тесно, там точно нужен скроллбар (не видно всего списка)?
>>104258
Ползунок - это палка с камнями на красном фоне. Мне было интересно покреативить и сделать что-то вычурное. В целом понятно, что всё в доработке нуждается, но как для пол дня работы я более чем доволен. А налезает он потому на список потому что я обкакался с шириной панелек списка, они слишком широкие и появляется горизонтальный скроллбар, потом поправлю. Скроллбар вертикальный точно нужен, потому что это список на пару десятков панелек.
Короче сделал просто потому что интересно было попробовать.
Ползунок - это палка с камнями на красном фоне. Мне было интересно покреативить и сделать что-то вычурное. В целом понятно, что всё в доработке нуждается, но как для пол дня работы я более чем доволен. А налезает он потому на список потому что я обкакался с шириной панелек списка, они слишком широкие и появляется горизонтальный скроллбар, потом поправлю. Скроллбар вертикальный точно нужен, потому что это список на пару десятков панелек.
Короче сделал просто потому что интересно было попробовать.
Господа, а есть какой-то адекватный бенчмарк итд касательно того, насколько хорошо/хуево все у годо с 3Д в плане производительности? Помню времена 3.5, когда любой спавн объекта вызывал фризы из-за компиляции шейдеров, ну и куллинга не было. Щас с этим как?
>>104417
Чужие бенчмарки это зло (зачастую из-за ошибок или предвзятости). Попробуй сделать две демки с интересующими фичами (желательно в нагрузке, а не куб на 1000фпс) и решить для себя без холивара.
Чужие бенчмарки это зло (зачастую из-за ошибок или предвзятости). Попробуй сделать две демки с интересующими фичами (желательно в нагрузке, а не куб на 1000фпс) и решить для себя без холивара.
>>104417
Не любой, а только первый с новым шейдером. Поэтому спокойно можно было предзагрузить все шейдеры на экране загрузки, налепив их на кубы, вращающиеся перед камерой.
Куллинг был в 3.5. Там окклюдеры как раз добавили.
Так что, 3.5 отличная версия для 3д. Хотя, сейчас сижу на 3.6-3.7
> любой спавн объекта вызывал фризы из-за компиляции шейдеров
Не любой, а только первый с новым шейдером. Поэтому спокойно можно было предзагрузить все шейдеры на экране загрузки, налепив их на кубы, вращающиеся перед камерой.
>и куллинга не было.
Куллинг был в 3.5. Там окклюдеры как раз добавили.
Так что, 3.5 отличная версия для 3д. Хотя, сейчас сижу на 3.6-3.7
97 Кб, 904x1294>>104417
Ты не сможешь сделать конкурентную игру в однопотоке. Осваивай многопоточность. Без неё никуда. Ты не избавишься от фризов, если меши с текстурами будут грузиться в память в том же потоке, в котором работает основная деревосцена. Накодил обёртку для отправки определенных действий в отдельный поток с возвратом результата, и пользуешься.
Ты не сможешь сделать конкурентную игру в однопотоке. Осваивай многопоточность. Без неё никуда. Ты не избавишься от фризов, если меши с текстурами будут грузиться в память в том же потоке, в котором работает основная деревосцена. Накодил обёртку для отправки определенных действий в отдельный поток с возвратом результата, и пользуешься.
>>104506
Лол нет. Зачем?
Лол нет. Зачем?
>>104436
А можно как-то автоматизировать, чтобы как в современных ААА-играх - при первом запуске после установки или после патча полчаса компилил шейдеры а потом всегда мгновенный запуск?
А можно как-то автоматизировать, чтобы как в современных ААА-играх - при первом запуске после установки или после патча полчаса компилил шейдеры а потом всегда мгновенный запуск?
>>104521
А оно разве так работает? У меня стимовские Одиссея и Детройт с рандомного нихуя решали шейдеры перекэшировать, без апдейтов.
>полчаса компилил шейдеры а потом всегда мгновенный запуск?
А оно разве так работает? У меня стимовские Одиссея и Детройт с рандомного нихуя решали шейдеры перекэшировать, без апдейтов.
>>104252
Если сможешь сделать такую же волнистую обводку как у самих панелек - будет хорошо. А пока что слишком сильно выбивается из общего стиля, мне кажется, из-за слишком большого числа оттенков в градиенте и слишком прямых линий, когда все остальные извилистые... и из-за чисто чёрного цвета. Внешне больше напоминает разукрашенную кость... может, из-за красного цвета? Будто мясо/кровь.
>>104417 >>104521
Ну, не знаю, попробуй официальные 3D демки с гитахаба скачать? Там есть прям графонистые, на которых мейнтейнеры тестировали всякие новые фичи/багфиксы разных рендереров движка. Я сам не тестировал, но читал где-то, что демка-шутер прям жёстко грузит комп шейдерами - на ней же тестировали "убершейдер" или что-то вроде того. Полистай новости на официальном сайте.
А лучше всего - читать документацию:
https://docs.godotengine.org/en/stable/tutorials/performance/pipeline_compilations.html
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html
>>104502 >>104504
Я тебя в следующий раз за такой жирный троллинг репортить буду... RTFM:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
И не пытайся изобретать велосипед с нейронкой, если ты не троллишь так.
Алсо в тему потоков:
https://docs.godotengine.org/en/stable/tutorials/performance/thread_safe_apis.html#scene-tree
>>104522
У него какая-то старая игра в гугл плей... или это браузерка. Если обновится до 4.x - потеряет часть уже имеющейся ЦА... Или это другой анон, который ковыряется в C# вместо GDScript, а игру так и не сделал... Кажется, тут отписывались минимум двое, застрявшие на 3.x по разным причинам.
Если сможешь сделать такую же волнистую обводку как у самих панелек - будет хорошо. А пока что слишком сильно выбивается из общего стиля, мне кажется, из-за слишком большого числа оттенков в градиенте и слишком прямых линий, когда все остальные извилистые... и из-за чисто чёрного цвета. Внешне больше напоминает разукрашенную кость... может, из-за красного цвета? Будто мясо/кровь.
>>104417 >>104521
>адекватный бенчмарк 3Д в плане производительности
Ну, не знаю, попробуй официальные 3D демки с гитахаба скачать? Там есть прям графонистые, на которых мейнтейнеры тестировали всякие новые фичи/багфиксы разных рендереров движка. Я сам не тестировал, но читал где-то, что демка-шутер прям жёстко грузит комп шейдерами - на ней же тестировали "убершейдер" или что-то вроде того. Полистай новости на официальном сайте.
А лучше всего - читать документацию:
>фризы из-за компиляции шейдеров
https://docs.godotengine.org/en/stable/tutorials/performance/pipeline_compilations.html
>куллинг
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html
>>104502 >>104504
Я тебя в следующий раз за такой жирный троллинг репортить буду... RTFM:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
И не пытайся изобретать велосипед с нейронкой, если ты не троллишь так.
Алсо в тему потоков:
https://docs.godotengine.org/en/stable/tutorials/performance/thread_safe_apis.html#scene-tree
>Still, this is only really useful if you have one thread loading data. Attempting to load or create scene chunks from multiple threads may work, but you risk resources (which are only loaded once in Godot) being tweaked by the multiple threads, resulting in unexpected behaviors or crashes.
>>104522
У него какая-то старая игра в гугл плей... или это браузерка. Если обновится до 4.x - потеряет часть уже имеющейся ЦА... Или это другой анон, который ковыряется в C# вместо GDScript, а игру так и не сделал... Кажется, тут отписывались минимум двое, застрявшие на 3.x по разным причинам.
>>104252
Если сможешь сделать такую же волнистую обводку как у самих панелек - будет хорошо. А пока что слишком сильно выбивается из общего стиля, мне кажется, из-за слишком большого числа оттенков в градиенте и слишком прямых линий, когда все остальные извилистые... и из-за чисто чёрного цвета. Внешне больше напоминает разукрашенную кость... может, из-за красного цвета? Будто мясо/кровь.
>>104417 >>104521
Ну, не знаю, попробуй официальные 3D демки с гитахаба скачать? Там есть прям графонистые, на которых мейнтейнеры тестировали всякие новые фичи/багфиксы разных рендереров движка. Я сам не тестировал, но читал где-то, что демка-шутер прям жёстко грузит комп шейдерами - на ней же тестировали "убершейдер" или что-то вроде того. Полистай новости на официальном сайте.
А лучше всего - читать документацию:
https://docs.godotengine.org/en/stable/tutorials/performance/pipeline_compilations.html
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html
>>104502 >>104504
Я тебя в следующий раз за такой жирный троллинг репортить буду... RTFM:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
И не пытайся изобретать велосипед с нейронкой, если ты не троллишь так.
Алсо в тему потоков:
https://docs.godotengine.org/en/stable/tutorials/performance/thread_safe_apis.html#scene-tree
>>104522
У него какая-то старая игра в гугл плей... или это браузерка. Если обновится до 4.x - потеряет часть уже имеющейся ЦА... Или это другой анон, который ковыряется в C# вместо GDScript, а игру так и не сделал... Кажется, тут отписывались минимум двое, застрявшие на 3.x по разным причинам.
Если сможешь сделать такую же волнистую обводку как у самих панелек - будет хорошо. А пока что слишком сильно выбивается из общего стиля, мне кажется, из-за слишком большого числа оттенков в градиенте и слишком прямых линий, когда все остальные извилистые... и из-за чисто чёрного цвета. Внешне больше напоминает разукрашенную кость... может, из-за красного цвета? Будто мясо/кровь.
>>104417 >>104521
>адекватный бенчмарк 3Д в плане производительности
Ну, не знаю, попробуй официальные 3D демки с гитахаба скачать? Там есть прям графонистые, на которых мейнтейнеры тестировали всякие новые фичи/багфиксы разных рендереров движка. Я сам не тестировал, но читал где-то, что демка-шутер прям жёстко грузит комп шейдерами - на ней же тестировали "убершейдер" или что-то вроде того. Полистай новости на официальном сайте.
А лучше всего - читать документацию:
>фризы из-за компиляции шейдеров
https://docs.godotengine.org/en/stable/tutorials/performance/pipeline_compilations.html
>куллинг
https://docs.godotengine.org/en/stable/tutorials/3d/occlusion_culling.html
>>104502 >>104504
Я тебя в следующий раз за такой жирный троллинг репортить буду... RTFM:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
И не пытайся изобретать велосипед с нейронкой, если ты не троллишь так.
Алсо в тему потоков:
https://docs.godotengine.org/en/stable/tutorials/performance/thread_safe_apis.html#scene-tree
>Still, this is only really useful if you have one thread loading data. Attempting to load or create scene chunks from multiple threads may work, but you risk resources (which are only loaded once in Godot) being tweaked by the multiple threads, resulting in unexpected behaviors or crashes.
>>104522
У него какая-то старая игра в гугл плей... или это браузерка. Если обновится до 4.x - потеряет часть уже имеющейся ЦА... Или это другой анон, который ковыряется в C# вместо GDScript, а игру так и не сделал... Кажется, тут отписывались минимум двое, застрявшие на 3.x по разным причинам.
>>104522
Как выше сказали, во-первых, html-версии, не хочется раздувать (хотя я давно не проверял, может в 4-ке как то оптимизнули размер билда-время загрузки). Дело не только в браузерках - это просто удобно, скинуть бетатестеру или издателю демку, выложить на джеме чтобы больше игроков поиграло.
Во-вторых, мне меньше зашел редактор кода 4-ки. В-третьих, на твг оказалось, что у двачеров даже пк версия 4-ки не тянет на их некропека. Конечно, это может быть неважно, если делаешь на платежеспособных покупателей в стиме, но может быть важно, если хочешь покрыть больше аудиторию, включая low end. В-четвертых, я вулкану не очень доверяю. Был неприятный опыт в первые годы, все крашилось, все глитчило квадратами.
Из минусов, аддоны давно только на 4-ку пишут. Процентов 90%, наверное, можно конвертнуть нейронкой, но не визуальные, где используются новые фишки рендера. Не хватает нововведений шейдеров, типа global uniforms. Compute shader и stencil там только очень условно, в виде- отрендерить что-то, потом считать текстуру gpu->cpu.
Как выше сказали, во-первых, html-версии, не хочется раздувать (хотя я давно не проверял, может в 4-ке как то оптимизнули размер билда-время загрузки). Дело не только в браузерках - это просто удобно, скинуть бетатестеру или издателю демку, выложить на джеме чтобы больше игроков поиграло.
Во-вторых, мне меньше зашел редактор кода 4-ки. В-третьих, на твг оказалось, что у двачеров даже пк версия 4-ки не тянет на их некропека. Конечно, это может быть неважно, если делаешь на платежеспособных покупателей в стиме, но может быть важно, если хочешь покрыть больше аудиторию, включая low end. В-четвертых, я вулкану не очень доверяю. Был неприятный опыт в первые годы, все крашилось, все глитчило квадратами.
Из минусов, аддоны давно только на 4-ку пишут. Процентов 90%, наверное, можно конвертнуть нейронкой, но не визуальные, где используются новые фишки рендера. Не хватает нововведений шейдеров, типа global uniforms. Compute shader и stencil там только очень условно, в виде- отрендерить что-то, потом считать текстуру gpu->cpu.
>>104679
Там по умолчанию "всё включено" - если хочешь оптимизировать, то нужно делать свою сборку, отключая флагами компилятора все ненужные модули движка. Насколько я помню, основные проблемы Godot 4 в браузерах не из-за размера файла. Кажется, кто-то на звук жаловался, и ещё что-то про C# было, а в остальном вроде норм. Но я бы не ждал ничего хорошего от веба.
Что именно не так? Вроде, только новые QoL-фичи добавили, остальное по-старому.
Можно сделать кастомный SSE2-only билд, изменив всего пару строчек в scons скриптах (могу подсказать, какие), либо использовать официальную x86_32-сборку (будет доступно максимум 4 Гб оперативки, но вряд ли это кого-то волнует на таком старом ПК). Эта проблема началась с 4.5+ версии движка, 4.4 норм. В остальном, если ПК тянет Windows 10, то и Godot 4.x потянет.
Насколько я понял, масса проблем с Vulkan только на Windows, и поэтому специально для Windows разрабы Godot добавили поддержку DirectX12, и он теперь выбирается сразу во всех новых проектах 4.x. Кроме того, ничто не мешает запускать с OpenGL3 через Compatibility. Впрочем, лично у меня особых проблем с Vulkan на Windows не возникало за эти годы.
Ну, версии 4.0-4.1-4.2 были самыми глючными. Потом всё стабилизировалось.
По моим наблюдениям - многие аддоны либо слишком банальные (можно написать лучше за вечер и не указывать в авторах какого-то школьника), либо слишком перегруженные (очень много параметров, ненужных тебе - дешевле сделать свой лёгкий велосипед), либо просто непонятное месиво с нарушением всех норм и поломкой после каждого обновления... Да и зачастую аддоны выглядят как-то чуждо интерфейсам Godot, то есть придётся долго к ним привыкать и переключать ментальный контекст постоянно. Так что не многое теряешь в плане аддонов. А я вот привык к QoL-фичам и поэтому не могу вернуться на 3.x (где-то год назад пробовал - сильно раздражало, несмотря на то, что начинал осваивать Godot во времена 3.2).
>оптимизнули размер билда
Там по умолчанию "всё включено" - если хочешь оптимизировать, то нужно делать свою сборку, отключая флагами компилятора все ненужные модули движка. Насколько я помню, основные проблемы Godot 4 в браузерах не из-за размера файла. Кажется, кто-то на звук жаловался, и ещё что-то про C# было, а в остальном вроде норм. Но я бы не ждал ничего хорошего от веба.
>мне меньше зашел редактор кода 4-ки
Что именно не так? Вроде, только новые QoL-фичи добавили, остальное по-старому.
>у двачеров даже пк версия 4-ки не тянет на их некропека
Можно сделать кастомный SSE2-only билд, изменив всего пару строчек в scons скриптах (могу подсказать, какие), либо использовать официальную x86_32-сборку (будет доступно максимум 4 Гб оперативки, но вряд ли это кого-то волнует на таком старом ПК). Эта проблема началась с 4.5+ версии движка, 4.4 норм. В остальном, если ПК тянет Windows 10, то и Godot 4.x потянет.
>вулкану не очень доверяю. Был неприятный опыт
Насколько я понял, масса проблем с Vulkan только на Windows, и поэтому специально для Windows разрабы Godot добавили поддержку DirectX12, и он теперь выбирается сразу во всех новых проектах 4.x. Кроме того, ничто не мешает запускать с OpenGL3 через Compatibility. Впрочем, лично у меня особых проблем с Vulkan на Windows не возникало за эти годы.
>все крашилось, все глитчило квадратами
Ну, версии 4.0-4.1-4.2 были самыми глючными. Потом всё стабилизировалось.
>аддоны давно только на 4-ку пишут
По моим наблюдениям - многие аддоны либо слишком банальные (можно написать лучше за вечер и не указывать в авторах какого-то школьника), либо слишком перегруженные (очень много параметров, ненужных тебе - дешевле сделать свой лёгкий велосипед), либо просто непонятное месиво с нарушением всех норм и поломкой после каждого обновления... Да и зачастую аддоны выглядят как-то чуждо интерфейсам Godot, то есть придётся долго к ним привыкать и переключать ментальный контекст постоянно. Так что не многое теряешь в плане аддонов. А я вот привык к QoL-фичам и поэтому не могу вернуться на 3.x (где-то год назад пробовал - сильно раздражало, несмотря на то, что начинал осваивать Godot во времена 3.2).
>>104679
Там по умолчанию "всё включено" - если хочешь оптимизировать, то нужно делать свою сборку, отключая флагами компилятора все ненужные модули движка. Насколько я помню, основные проблемы Godot 4 в браузерах не из-за размера файла. Кажется, кто-то на звук жаловался, и ещё что-то про C# было, а в остальном вроде норм. Но я бы не ждал ничего хорошего от веба.
Что именно не так? Вроде, только новые QoL-фичи добавили, остальное по-старому.
Можно сделать кастомный SSE2-only билд, изменив всего пару строчек в scons скриптах (могу подсказать, какие), либо использовать официальную x86_32-сборку (будет доступно максимум 4 Гб оперативки, но вряд ли это кого-то волнует на таком старом ПК). Эта проблема началась с 4.5+ версии движка, 4.4 норм. В остальном, если ПК тянет Windows 10, то и Godot 4.x потянет.
Насколько я понял, масса проблем с Vulkan только на Windows, и поэтому специально для Windows разрабы Godot добавили поддержку DirectX12, и он теперь выбирается сразу во всех новых проектах 4.x. Кроме того, ничто не мешает запускать с OpenGL3 через Compatibility. Впрочем, лично у меня особых проблем с Vulkan на Windows не возникало за эти годы.
Ну, версии 4.0-4.1-4.2 были самыми глючными. Потом всё стабилизировалось.
По моим наблюдениям - многие аддоны либо слишком банальные (можно написать лучше за вечер и не указывать в авторах какого-то школьника), либо слишком перегруженные (очень много параметров, ненужных тебе - дешевле сделать свой лёгкий велосипед), либо просто непонятное месиво с нарушением всех норм и поломкой после каждого обновления... Да и зачастую аддоны выглядят как-то чуждо интерфейсам Godot, то есть придётся долго к ним привыкать и переключать ментальный контекст постоянно. Так что не многое теряешь в плане аддонов. А я вот привык к QoL-фичам и поэтому не могу вернуться на 3.x (где-то год назад пробовал - сильно раздражало, несмотря на то, что начинал осваивать Godot во времена 3.2).
>оптимизнули размер билда
Там по умолчанию "всё включено" - если хочешь оптимизировать, то нужно делать свою сборку, отключая флагами компилятора все ненужные модули движка. Насколько я помню, основные проблемы Godot 4 в браузерах не из-за размера файла. Кажется, кто-то на звук жаловался, и ещё что-то про C# было, а в остальном вроде норм. Но я бы не ждал ничего хорошего от веба.
>мне меньше зашел редактор кода 4-ки
Что именно не так? Вроде, только новые QoL-фичи добавили, остальное по-старому.
>у двачеров даже пк версия 4-ки не тянет на их некропека
Можно сделать кастомный SSE2-only билд, изменив всего пару строчек в scons скриптах (могу подсказать, какие), либо использовать официальную x86_32-сборку (будет доступно максимум 4 Гб оперативки, но вряд ли это кого-то волнует на таком старом ПК). Эта проблема началась с 4.5+ версии движка, 4.4 норм. В остальном, если ПК тянет Windows 10, то и Godot 4.x потянет.
>вулкану не очень доверяю. Был неприятный опыт
Насколько я понял, масса проблем с Vulkan только на Windows, и поэтому специально для Windows разрабы Godot добавили поддержку DirectX12, и он теперь выбирается сразу во всех новых проектах 4.x. Кроме того, ничто не мешает запускать с OpenGL3 через Compatibility. Впрочем, лично у меня особых проблем с Vulkan на Windows не возникало за эти годы.
>все крашилось, все глитчило квадратами
Ну, версии 4.0-4.1-4.2 были самыми глючными. Потом всё стабилизировалось.
>аддоны давно только на 4-ку пишут
По моим наблюдениям - многие аддоны либо слишком банальные (можно написать лучше за вечер и не указывать в авторах какого-то школьника), либо слишком перегруженные (очень много параметров, ненужных тебе - дешевле сделать свой лёгкий велосипед), либо просто непонятное месиво с нарушением всех норм и поломкой после каждого обновления... Да и зачастую аддоны выглядят как-то чуждо интерфейсам Godot, то есть придётся долго к ним привыкать и переключать ментальный контекст постоянно. Так что не многое теряешь в плане аддонов. А я вот привык к QoL-фичам и поэтому не могу вернуться на 3.x (где-то год назад пробовал - сильно раздражало, несмотря на то, что начинал осваивать Godot во времена 3.2).
>>104687
А нечего там флагами отключать, просто по мелочам все копится, там новые функции, там новые ноды, там новые системы. Отключать проигрыватель webm копейки экономит, а 3д можно только целиком отключить.
В редакторе, мы в треде выясняли, как то по другому автодополнение работает, вылезает не то, что было в 3ке.
Не знаю, причем тут SSE2, как раз на 4.4 тоже у двачеров тормозило. DX не пробовал.
Можно конечно и переписывать аддоны, но это уже отчасти NIH. А какая разница, что надо школьников указывать? Все равно в идеале надо указывать лицензии на все либы MIT, Apache использованные в годоте, так что туда же дописать и аддоны.
Не знаю, что тебе за QoL так важны, они, возможно, улучшают что-то поверх 4.0, а в 3-ке были аналоги - например, в 4.7 добавили превью 3д камеры в инспекторе - так в 3ке это было аддоном еще в 2021 году.
А нечего там флагами отключать, просто по мелочам все копится, там новые функции, там новые ноды, там новые системы. Отключать проигрыватель webm копейки экономит, а 3д можно только целиком отключить.
В редакторе, мы в треде выясняли, как то по другому автодополнение работает, вылезает не то, что было в 3ке.
Не знаю, причем тут SSE2, как раз на 4.4 тоже у двачеров тормозило. DX не пробовал.
Можно конечно и переписывать аддоны, но это уже отчасти NIH. А какая разница, что надо школьников указывать? Все равно в идеале надо указывать лицензии на все либы MIT, Apache использованные в годоте, так что туда же дописать и аддоны.
Не знаю, что тебе за QoL так важны, они, возможно, улучшают что-то поверх 4.0, а в 3-ке были аналоги - например, в 4.7 добавили превью 3д камеры в инспекторе - так в 3ке это было аддоном еще в 2021 году.
>>104687
А звук в вебе в 3-ке гоняю через форк js либы, сразу в mp3 средствами браузера, и не требует включать многопоток с sharedarraybuffers
А звук в вебе в 3-ке гоняю через форк js либы, сразу в mp3 средствами браузера, и не требует включать многопоток с sharedarraybuffers
>>104687
Особенно с учетом того что полностью умер.
-Крупные киты захватили всю аудиторию, все сидят на 1,5 сайте или же вообще в приложении.
-Раньше была проблема первой страницы поиска, потом трех первых ссылок, а теперь вообще плашка ИИ гугла не отдает трафика (Zero-Click Search).
-Буратино проще клацнуть и купить в стиме, чем разбираться в твоих вебах, которые чаще перегружены визуально.
-Еще и очкуны будут (руткиты стима свои, любимые, а эти чужие, фу).
-Ну еще за сервер платить, дрочиться с оптимизацией, а потом все равно охеревать когда говнина упадет в праймтайм, а админ раздуплиться только завтра (админ в дата центре, своему еще платить).
Но если трафик есть и он стабилен (что на уровне чуда) - то да, меньше посредников сосущие твои деньги.
>Но я бы не ждал ничего хорошего от веба.
Особенно с учетом того что полностью умер.
-Крупные киты захватили всю аудиторию, все сидят на 1,5 сайте или же вообще в приложении.
-Раньше была проблема первой страницы поиска, потом трех первых ссылок, а теперь вообще плашка ИИ гугла не отдает трафика (Zero-Click Search).
-Буратино проще клацнуть и купить в стиме, чем разбираться в твоих вебах, которые чаще перегружены визуально.
-Еще и очкуны будут (руткиты стима свои, любимые, а эти чужие, фу).
-Ну еще за сервер платить, дрочиться с оптимизацией, а потом все равно охеревать когда говнина упадет в праймтайм, а админ раздуплиться только завтра (админ в дата центре, своему еще платить).
Но если трафик есть и он стабилен (что на уровне чуда) - то да, меньше посредников сосущие твои деньги.
20 Кб, 1162x678>>104673
Я уже перескейлил и доработал палку, как и подложку под неё. И в целом позанимался немного еще интерфейсом, порисовал найн-патчи. Пока просто экспериментирую, делаю рандомную херню и смотрю, как она выглядит в результате.
Это кстати очень весело, наверно мне больше всего нравится интерфейсики рисовать в геймдеве. Не так много времени занимает, и результат виден практически сразу.
Я уже перескейлил и доработал палку, как и подложку под неё. И в целом позанимался немного еще интерфейсом, порисовал найн-патчи. Пока просто экспериментирую, делаю рандомную херню и смотрю, как она выглядит в результате.
Это кстати очень весело, наверно мне больше всего нравится интерфейсики рисовать в геймдеве. Не так много времени занимает, и результат виден практически сразу.
>>104721
Тело ползунка сливается с фоном скролла.
Я хз как у вас в писеляче принято, но у меня глаза вытекают.
Тело ползунка сливается с фоном скролла.
Я хз как у вас в писеляче принято, но у меня глаза вытекают.