Шапка: https://hipolink.me/godothread
Предыдущий 82: >>1097332 (OP)
---
Maintenance release: Godot 4.7.2: https://godotengine.org/article/maintenance-release-godot-4-7-2/
Maintenance release: Godot 3.6.3: https://godotengine.org/article/maintenance-release-godot-3-6-3/
Все версии, скачать: https://github.com/godotengine/godot-builds/releases
Я не сделал игру.
Анатолий Э. Тавомалов
Пока что скрестил элементы из пары проектов и немного смоделил пушки из мешинстанстов. Думаю ещё начну постепенно глубже изучать блендер, чтобы делать более приятную глазу картинку если не задушусь, в таком случае всё будет как будет
Ого, ты вернулся, а то я думал, куда ты пропал...
А что с тем киберпанк-шутером со световыми мечами? Почему бы не добавить выживание, РПГ-прокачку и квесты в открытом мире прямо туда? Мне кажется, киберпанк-сеттинг с крысами-мутантами и всякими киборгами интереснее, чем очередной "казуальный выживач" в лесу с охотничьим ружьём.
Но ладно. По видео могу сказать: если это глухой лес и игрок будет проводить в нём кучу времени, ища ресурсы и борясь с животными/монстрами, то тебе обязательно нужен ландшафт с холмами, оврагами, обрывами, речушками, какими-нибудь пещерами/канализацией (лол, рядом с городом бывает и такое: идёшь по лесу, а там раз - бетонная дырка канализации посреди ничего, как какой-то артефакт древней цивилизации) и другими подобными деталями местности. Потому что бегать по плоскости будет очень скучно, и это довольно нереалистично, на мой взгляд. Поэтому первым делом нужно сделать/скачать и протестировать ландшафт. Не обязательно воксельный, на картах высот можно сделать много чего интересного. Взаимодействие с ландшафтом в 3D выживалке очень важно.
А "приятная глазу картинка" складывается в основном из работы с текстурами (особенно если это стилизованная игра) и написания кастомных шейдеров. На одних только мешах из блендера ты не уедешь далеко, и, ИМХО, работать по ААА-пайплайну (хайполи печётся в лоуполи) намного дольше и сложнее, чем просто покрасить лоуполи/мидлполи мультяшными/пережатыми текстурками и потом щедро обмазаться динамичными шейдерами в движке. В общем-то, твоя киберпанк игра уже неплохо выглядела для своей ниши, а с этим выживанием в лесу ты непонятно чего добиваешься...
>выживач
Снес ракетницей белочку, распилил ветки деревьев пулеметом, разжег костёр гранатой - сготовил белочку, выжил.
Грубо говоря так и будет! А крафт будет выглядеть как просто скидывание категоризированных предметов в кучу две штуки второго тира кожи соединяем с первым тиром ветки и получаем палатку в которой восстанавливаем здоровье и силы
>>1105125
>Ого, ты вернулся, а то я думал, куда ты пропал...
>А что с тем киберпанк-шутером со световыми мечами?
А я как раз им и занимался. В целом. Всё основное что хотел там сделать, было сделано кроме мультиплеера, но на него уже не осталось моральных сил и после демо фестиваля в стиме в октябре она выйдет. Компания и сюжет есть. Боевка и прогрессия есть. Фарм валюты для покупки скинов и пара арен для аутирования тоже. Можно было бы дальше игру шлифовать и наполнять контентом, но я уже немного устал от неё и есть ощущение бессмысленности перед последующими стараниями, поэтому пусть всё будет как будет, посмотрю отзывы в будущем и сделаю выводы для будущей части хочу развивать эту серию и в целом вселенную с широким таймлайном
>Почему бы не добавить выживание, РПГ-прокачку и квесты в открытом мире прямо туда? Мне кажется, киберпанк-сеттинг с крысами-мутантами и всякими киборгами интереснее, чем очередной "казуальный выживач" в лесу с охотничьим ружьём.
Вообщеееее... Изначально так и планировал. И собсна кирпичики складывал ещё в самурайской игре. Но по нескольким причинам решил взять за основу другой контроллер персонажа:
1) Я в целом устал от прошлого контроллера, поэтому нужно переключиться на что-то новое.
2) Я хотел добавить больше стилей борьбы и развитие боев на мечах, рукопашку, больше пушек, выживание как в метал гире 3, а так же улучшить графику. Но, честно говоря, думаю этот "вес" я пока не смогу осилить речь не только про программирование, но и модели и левел дизайн, и будет правильней отработать часть механик и подтянуть скилы на проекте по проще.
Поэтому в общем чет посидев и покурив, вспомнил про старый иммерсив сим темплейт для годота, COGITO, в целом давно его заприметил, и так же давно хотел начать пробовать на нём что-то запилить, но был занят самураем. В итоге скачал его и посмотрел. В целом прикольный аддон, но потыкавшись, геймплейно мне он показался каким-то топорным, да и те вещи, которые хотелось бы украсть, можно впринципе и самому и понятней для себя сделать, поэтому взглянул на один свой джемовый проект. Ну и тут собственно появился образ будущей игры, иммерсивный выживач, где в безопасных деревнях можно пить пиво и делать квесты, а за их пределами преодолевать многокиллометровые расстояния и выживать в дикой местности.
>Мне кажется, киберпанк-сеттинг с крысами-мутантами и всякими киборгами интереснее, чем очередной "казуальный выживач" в лесу с охотничьим ружьём.
Игра планируется как приквел, в котором закину удочку на эволюцию крыс. Грубо говоря это постапокалипсис в тайге с мутантами, и военными структурами подчиняющими местных голожопых аборигенов. В целом мне кажется этот сеттинг не менее интересным, и развить его можно прям вообще в любую сторону.
>если это глухой лес и игрок будет проводить в нём кучу времени, ища ресурсы и борясь с животными/монстрами, то тебе обязательно нужен ландшафт с холмами, оврагами, обрывами, речушками, какими-нибудь пещерами/канализацией (лол, рядом с городом бывает и такое: идёшь по лесу, а там раз - бетонная дырка канализации посреди ничего, как какой-то артефакт древней цивилизации) и другими подобными деталями местности
Спасибо что сказал про обрывы и канализации, добавил в список. А так да. Грубо говоря часть времени нужно будет выживать на природе, не только леса, горы, пустыши, развалины, речки.
>Поэтому первым делом нужно сделать/скачать и протестировать ландшафт. Не обязательно воксельный, на картах высот можно сделать много чего интересного. Взаимодействие с ландшафтом в 3D выживалке очень важно.
Хорошо, понял. Щас в ближайшее время закончу с функционалом пушек, и начну гуглить в эту сторону.
>А "приятная глазу картинка" складывается в основном из работы с текстурами (особенно если это стилизованная игра) и написания кастомных шейдеров
Вообще, так погуглив, насколько понял важна работа с материалами для текстур пик, это типа базовый минимум для каждой модели, который щас все делают. Ну и сами текстуры конечно нужны.
>На одних только мешах из блендера ты не уедешь далеко, и, ИМХО, работать по ААА-пайплайну (хайполи печётся в лоуполи) намного дольше и сложнее, чем просто покрасить лоуполи/мидлполи мультяшными/пережатыми текстурками и потом щедро обмазаться динамичными шейдерами в движке.
В целом, самостоятельно я все равно не вывезу хайполи, да и через чур много времени будет на модели уходить, поэтому продолжаю склонятся к лоу поли, но с большим числом полигонов и нормально выделеными материалами.
>В общем-то, твоя киберпанк игра уже неплохо выглядела для своей ниши
Спасибо!
>а с этим выживанием в лесу ты непонятно чего добиваешься...
В целом, я примерно такой образ представляю, будто в первой халфе моддер делает камерную природную локацию, но со вкраплениями бетона типа как когда выходишь к каньону в первой халфе, вроде ощущается масштаб, но и камерность ощущается. Но в целом, посмотрим что получится, свой корявый стиль конечно же органично интегрирую
К чему спрашиваю. Эта херня работает по принципу automatic lod, т.е. движок сам определяет какой array_index использовать. По идее, это должно быть лучше чем, допустим, сделать как обычно несколько lod для одного дерева и задать каждому свой visibility range.
1. Тут не будет никакого popin-popout.
2. Объект 1, а не равен количеству lod.
Единственный минус, что памяти немного больше займёт.
Я чёт подводных не вижу. Или они есть?
И да, понятное дело что количество материалов должно быть одинаковым для всех lods, а также array_tex_uv, array_normal и прочие должны тоже присутствовать (ну или заполнить ничем лол) для всех lods.
Я не понял о чём ты спрашиваешь и что сделать хочешь. Модельки, которые ты импортируешь в Godot из любого формата сами превращаются в ArrayMesh.
По умолчанию в импортере стоит галочка Generate LOD которая и LODы из модели генерирует,
https://docs.godotengine.org/en/4.7/tutorials/3d/mesh_lod.html
Это то понятно, но можно использовать тот же инструмент, чтобы лоды не генерировались, а использовались твои, сделанные в том же блендер.
Можно и свои, но придётся чутка напрячься - или написать свой импортер, или выключить генерацию LODов и подставлять разные модели, в зависимости от расстояния до камеры, или воспользоваться аддоном https://github.com/puchik/godot-importance-lod или послушать свежую лекцию Кейси Муратори (пик), который показывает что ещё в 1974г Дональд Кнут писал в статье, что нефиг оптимизировать раньше времени.
Так вот я и спрашиваю, нет ли подводных.
>в зависимости от расстояния до камеры
Там немного не так работает. Оценивается не расстояние до камеры, а какой screen ratio объект на экране занимает.
Можешь попробовать послушать тут https://www.youtube.com/watch?v=l0O7KUME_K0
я не смотрел.
Про подводные я не знаю....
>Тут не будет никакого popin-popout
Почему так считаешь? Там же чётко сказано: нужно указывать float, который примерно пропорционален расстоянию, на котором LOD используется. То есть, указываешь неправильное число - будет заметно невооружённым глазом или будет бестолковым.
>Объект 1, а не равен количеству lod
Щас бы экономить на объектах...
>минус, что памяти немного больше займёт
Ты же сам сказал, что объектов меньше, лол.
>Я чёт подводных не вижу. Или они есть?
Подводные в том, что ты неправильно понимаешь:
>сделать как обычно несколько lod для одного дерева и задать каждому свой visibility range.
Настройка visibility range на нодах необходима для автоматической подмены нескольких нод одной. Ну, помнишь пасту Кирилла про корованы? Там он писал наподобие "деревья вдалеке картинкой" - так раньше повсеместно было, да и сейчас, думаю, тоже юзают.
Например, у тебя есть город. Когда игрок на улице, то детальные модели домов грузятся по отдельности и отображаются как отдельные ноды. Но когда игрок забирается в горы или на самолёте летит, весь город отображается одним лоуполи мешем - одной нодой.
С помощью LOD в ArrayMesh ты такого в принципе не сделаешь, потому что там ARRAY_INDEX - порядковые номера в ARRAY_VERTEX, ARRAY_UV и т.д. - т.е. у тебя уникальный массив точек, который РЕДУЦИРУЕТСЯ механизмом Level of Detail, а не просто подменяется.
Кроме того, использовать эту фичу через блендер не настолько просто, как кажется. Думаю, это больше процедурной геометрии подходит: чанков ландшафта, например, или чего-то подобного. Через Blender тебе придётся как-то... синхронизировать индексы мешей.
Пример: ты сделал восьмиугольник, шестиугольник и квадрат. У них разное число точек, но точки эти не совпадают друг с другом. Если квадрат ещё как-то вписывается в восьмиугольник (если увеличить), то шестиугольник имеет 2 вершины, которых у него нет.
Ещё нагрузка на GPU не столько от вершин, сколько материалов и текстур. Уменьшить нагрузку лучше с помощью упрощения шейдера и уменьшения числа обращения к текстурам. Но LOD в ArrayMesh будет использовать один и тот же материал с теми же UV.
Т.е. LOD через ArrayMesh - узкоспециализированная функция, хорошо подходящая только для простых хайпольных моделек, которые достаточно упрощать уменьшением массива индексов, без объединения с окружающими мешами и без изменений материала.
Алсо, для большой игры типа GTA 5 в любом случае потребуется писать велосипед - Godot пока не умеет в "asset streaming", который будет необходим, когда вес ассетов игры превышает объём RAM/VRAM у игрока. Жирные 150+ ГБ игры этим непрерывно занимаются.
P.S. Знаю это от интереса к процедурной генерации.
>То есть, указываешь неправильное число - будет заметно невооружённым глазом или будет бестолковым.
Ну так вот надо пытаться правильное.
>Ты же сам сказал, что объектов меньше, лол.
Ну так у тебя 1 базовый меш и 3 lod. 10к вершин, 2к, 500 и 20, итого 12520 вершин, памяти чуть больше займёт (хотя по факту также, т.к. память от упрощенных мешей теперь в одном). А объектов меньше, да.
>Через Blender тебе придётся как-то... синхронизировать индексы мешей.
Можно сделать в самом годо через скрипт. Тебе ж надо по сути сделать так
[lod0..........][lod1......][lod2...][lod3.]
Т.е. тупо присобачить нужные тебе вершины с нужным офсетом для конкретного lod. Вроде не сложно. Главное, как ты и написал, если в lod0 есть например uv2, то он во всех других должен быть.
Короче че пиздеть, завтра буду пробовать. А пока надо смену на заводе дожить.
Ты так и так вынужден подгонять числа, если хочешь смастерить свои собственные LODы. Избавиться от подгонки позволяет только механизм auto-LOD.
Память: отдельные меши имеют свои собственные ARRAY_VERTEX и т.п., а один меш будет иметь общие, поэтому памяти МЕНЬШЕ, чем если ты создаёшь LOD посредством отдельных объектов (mesh instance).
>[lod0..........][lod1......][lod2...][lod3.]
Хмм... Но тогда ты не экономишь память, и вообще непонятно, зачем ты это делаешь. Чтобы на нодах сэкономить, что ли? А почему тебе auto-LOD здесь не подходит? Выдаёт сильно некачественный вариант?
>завтра буду пробовать
У тебя есть, с чем работать? Я согласен с >>1105209
>нефиг оптимизировать раньше времени.
Если у тебя этот >>1105099 проект, то, мне кажется, рановато ты заботишься о LOD. Те же деревья... Ну, допустим, это самый маленький 3D LOD, ниже - это подменять 3D модели 2D спрайтами, не иначе...
>А почему тебе auto-LOD здесь не подходит? Выдаёт сильно некачественный вариант?
Именно. Хочу чтобы был 1 объект и о нем заботился auto lod. Но при этом lodы мои.
Ой, да делай как хочешь. Только потом не ной, что ты потратил две недели на код, который оказался тупо медленнее/жирнее по памяти/хуже по результату на экране... Тыщу раз такое было: придумываешь свой велосипед, долго его отлаживаешь, потом смотришь - колёса-то квадратные и заменить никак не выходит. Поэтому такие оптимизационные велосипеды стоит откладывать на потом, чтоб не растерять энтузиазм.
Основная причина, почему я хочу сделать с помощью auto lod, это чтобы выбор lod'a зависел от размера на экране, а не от расстояния до камеры. И он это как раз делает. А т.к. само редуцирование часто из говна, то было бы неплохо попробовать сделать свои.
Даже не знаю, с чего начать, но есть смутный вопрос/тема для обсуждения...
Не знаю, остались ли тут те, кто помнит, но в ноябре 2023 я где-то десяток дней потратил на свой собственный аддон для создания... хм, ветвящихся последовательностей чего-то? Задумывалось это как редактор на базе GraphEdit, который может быть полезен как для визуальной новеллы, так и для штук вроде катсцен и даже поведения NPC. Но это не скриптовый язык... Хотелось чего-то упрощённого, минимального, но позволяющего быстро накидать то, что роится в голове.
Основная фича: где не нужно ветвление, можно не создавать отдельные плавающие блоки и не возиться с ниточками: достаточно добавлять новые элементы в линейный блок-список. При этом элементы возможно перетаскивать из одного списка в другой мышкой и легко создавать новый, дропнув элемент в пустое пространство. Меньше развилок - граф меньше в ширину и больше в высоту. Также эти блоки-списки можно сворачивать в заголовок, чтобы можно было свернуть длинную портянку из десятков элементов и видеть только её входящие и исходящие связи. А у элементов списка могут быть теги для каких-то дополнительных функций (например, если это ВН, то удобно добавить тег-имя говорящего и тег-эмоцию, или тег-фон). Всё это GUI в той или иной степени реализовано на достаточно удобном уровне, и я вроде кидал скриншоты. Также была идея с созданием блоков-агрегатов, чтобы скрыть не только линейные портянки, но и все внутренние развилки, оставив только свободные точки входа и выхода из агрегата, но так и не дошёл до этой стадии, т.к. даже с сохранением/загрузкой возникли какие-то проблемы.
Как нетрудно догадаться, я забил на этот проект почти на три года. А на днях опять загорелось сделать что-то вроде визуальной новеллы/виртуального питомца, и я подумал - почему бы не попытаться довести этот аддон до юзабельного состояния, учитывая, что я сделал 80% от всего минимально необходимого. Начал изучать, что я наделал... И вспомнил одну проблему UI/UX, которую я тогда толком не смог решить концептуально: что делать с условными выражениями?
Но сначала поясню, зачем вообще нужны эти условия: смысл аддона в создании разветвлённых графов, а не просто линейных портянок; самый простой, базовый граф не имеет в себе никаких условий, и может быть использован для простой ВНки, где игроку доступны все выборы сразу; однако, более сложные сюжетные ветвления требуют условий разблокировки, как, например, "если есть зонтик и идёт дождь" разрешает ветку "предложить пойти вместе под одним зонтом" - необходимо где-то и как-то обозначить это условие, не так ли? Но... где?
Потенциальные варианты:
- сделать сложную форму для добавления условий (готово на 80%);
- сделать просто поле для ввода GDScript кода, и потом eval() его;
- сделать некий способ подключения функций на GDScript к графу.
Последнее я в целом планировал и без условий, то есть чтобы можно было вызывать функции, созданные на GDScript, прямо из графа, но без возврата значений; если использовать это для условных выражений, нужно будет возвращать и проверять bool для разблокировки ветки.
Изначально я начал делать форму с выпадающими списками и т.п., даже как отдельный блок, а потом подумал "зачем блок, если он будет использоваться только перед блоком-списком" и упаковал его в начало блока-списка, но потом... Что-то я засомневался, стоит ли эмулировать функциональность GDScript через такой GUI? Но если делать по-другому, не будет ли это как-то скрывать то, что реально вычисляется кодом, от внешнего представления графа в редакторе?
Даже не знаю, как иначе описать эту проблему. Мне кажется, я забил на этот проект в первую очередь из-за этой неопределённости с условиями... Где их отображать, как обрабатывать и т.д. Много неопределённого, что не так-то просто протестировать без сложного демо-проекта.
Знаю, что есть готовые решения для подобного, и я их смотрел - они мне как-то не нравятся. Текстовые скрипты мне не нравятся тем же, чем не нравится запись сценария на GDScript: все развилки становятся закопаны где-то в слоях линейного текста. Лапшичные редакторы зачастую страдают тем, что там одна реплика = один блок, и самый простой диалог вырастает в ширину очень быстро, что крайне неудобно, особенно когда каждый блок с кучей своих свистелок.
Что думаете? Чем вы пользуетесь для подобного? Как ощущения?
- Новая нода Trail3D для спецэффекта "ленточка" (Line3D могут добавить в будущем).
- Группировка нод визуальных шейдеров, позволяющая переиспользовать куски кода.
- Конвертация плагинов "главного экрана" в "доки" (docks); все экраны можно двигать.
- Список методов в редакторе скриптов теперь представлен в виде аккуратного дерева.
- Label и RichTextLabel смогут автоматически масштабировать текст, чтоб он умещался.
- Аппроксимация окружающего затенения (AO) со множественными отскоками света.
- Информация об отражённом свете (specular) теперь может запекаться в LightmapGI.
- Поддержка декалей в режиме Compatibility (есть несколько ограничений на число).
- Автоматическое скачивание и установка Android и Java SDK для экспорта на Android.
- Улучшение редактирования Polygon2D (по сути, фикс ошибки).
- Что-то связанное с анимациями - я не понял, лень разбираться...
- Фикс избыточного потребления ресурсов CPU в фоне (CoreAudio).
- Ускорение доступа к полям Object до x1.6 раз благодаря GDType.
- Превью замены текста во множестве файлов функции Find in Files.
- Кнопка для скрытия оверлея с метаданными в превью у текстуры.
- Очистка/упрощение заголовка инспектора (кнопки в бургер-меню).
- GDScript: предупреждение антипаттерна """строк-комментариев""".
- Разрешено провозглашать тост во время застолья с окошками!🥂
> Информация об отражённом свете (specular) теперь может запекаться в LightmapGI.
А ведь когда-то допрут до того, что запекать можно и вектор нормаля
Я бы рекомендовал посмотреть на старый добрый редактор квестов для Космических Рейнджеров (2), скорее всего он натолкнёт тебя на правильные мысли. Там конечно будут гейм-специфик константы, типа списка рас, такие вещи тебе у себя придётся перепридумать, как некие глобальные теги или переменные.
>Новая нода Trail3D для спецэффекта "ленточка"
Нечто переписывает код китайца на классы годота, используя ИИ (конечно я верю что он использовался только для поиска по коду, как оно пишет в первом сообщении)
В обзоре пишут что китаец taking a stab (пукнул-сренькнул, в контексте) в процессе своей реализации, но указывают что практически просто взяли его алгоритмы
Помогать нечту пришли все, только что сам Хуан не пришёл, все мегазанятые контрибуторы нашли время чтобы указать на проблемы в коде. Как починить что-то - так у них времени нет, постоянно пишут в статьях про это, как вычитывать кумовской нейрослоп - так пожалуйста, ведь надо помочь закрыть такой важный пропосал от этого нечто.
Как же тебя трудно читать, я нефига не понял. Можешь попросить нейронку чтобы она за тебя написала осмысленный текст?
Хуан, вроде, уже пару лет не пишет код, а занимается бизнесом W4.
>Поддержка декалей в режиме Compatibility (есть несколько ограничений на число).
вот это хорошо прям
Вести с полей. Расстановка 23788 деревьев. Без использования MultiMesh. Без нод, всё на RenderingServer.
Попробовал 3 способа. Autolod, создание 5 объектов с своим visibility_range (назовём VLOD) и моё предположение, назовём AutolodCastom. VLOD никаких фэйдинов и фэйдаутов нет, прост резкая замена.
В общем и целом по местам:
1. VLOD / AutolodCastom.
2. Autolod.
Суть в чём, если конечно сильно снизить порог threshold_pixel, то autolod станет более агрессивен, фпс сильно вырастет (как собственно и во всех других способах), но визуально будет так себе, слишком резкие попины/попауты.
VLOD грузит bvh-дерево, поэтому проц. время повыше.
К чему я это. Да просто.
>>1105367
>Но могут ли деревья расти?
Другой вопрос - будет ли игрок летать?
Это точно игра, а не развлекатель скуки? Зачем такая отрисовка того чего не увидит игрок?
Выглядит практически как авиасим ил-2
С другой стороны, это много где надо, даже просто в катсценах какой-то рпг.
Блин, меня во всех этих лодах всегда раздражает видимая горизонтальная полоса границы на экране. Я такое и в ААА играх вижу постоянно. МОжет, как то поэкспериментировать с рандомностью попинов
>С другой стороны, это много где надо, даже просто в катсценах какой-то рпг.
Не спорю что классно и сочно, но насколько практично?
Сильно было если дальние деревья превращались в спрайты.
А так вместо далеких деревьев хотелось бы оставить ресурсов на то что поближе (травушку, кустики, камушки, грибочки, лося, зайчика, врага итд).
Вот оптимизированная трава как-будто более необходима, потому что она скрывает плоскую землю, а пушистость вообще делает дорого богато.
crusader kings 3 - из-за моделек деревьев видюха греет комнату (в максимум вентиляторы на северных регионах), выключаешь и видюха тупо спит.
И вот думаешь - какого хрена, любители 3д деревьев на контурной карте.
Если ты имеешь ввиду где-то тут, то это тени.
Тут с PSSM4 экспериментировать надо, правильно split расставить.
Ну и зачем так делать?
Она не вызывается...
Ну, это само собой разумеется, так я и сделал, потому что так было принято в Delphi/FreePascal (там нет требования именно так называть конструктор, просто все стандартные классы имеют именно такое название конструктора). Но в GDScript экземпляры классов создаются через new(), а не create(), и это вызывает некоторый диссонанс, когда ты делаешь что-то типа:
>var button1 := MySimpleButton.new() # нода-кнопка
>var button2 := MyComplexButton.create() # сложная сцена с кучей нод внутри
Чувствуешь? Идеологически это одна и та же операция: создать экземпляр кусочка дерева сцены с какими-то настройками. Но в первом случае вызывается new() и всё работает, а у второго класса тоже есть new(), но вместо него приходится вызывать create(), иначе класс пукнет и обмякнет из-за того, что полагается на связанную с ним .tscn, а new() создаёт лишь ноду-корень.
При этом GDScript позволяет перезагрузить метод _init(), который вызывается при обращении к new(), и даже может иметь любое количество аргументов, которые будет нужно передать в new()... но не может ничего вернуть, потому что это не "конструктор экземпляра класса", а просто обработчик события "ты уже был создан, делай с этой информацией что хочешь".
Конечно, можно попытаться придумать костыль, когда корневая нода дожидается своего _ready() и только потом подгружает остальные свои ноды из отдельного .tscn. Но это неудобный костыль, требующий дополнительную корневую ноду (которой не может быть основная нода), и создающий диссонанс с привычной инициализацией объектов/сцен, принятой в Godot...
Но всё это не так уж и важно... Важно то, КАКОГО ХРЕНА МОЖНО ОБЪЯВИТЬ new(), ДАЖЕ static, И НЕ ПОЛУЧИТЬ СООБЩЕНИЯ ОБ ОШИБКЕ, ХОТЯ ЭТО, ОЧЕВИДНО, ОШИБОЧНАЯ СИТУАЦИЯ (объявленный new() не будет вызываться)? В Godot 4.8-dev4! Они уже кучу предупреждений добавили, в последней сборке даже "строки-комменты" помечают, а new() никого не волнует?
Т.е. я заранее понимал, что это должно быть неправильно, но ожидал, что IDE предупредит или Godot крашнется. Но нет...
>>1105509
>>1105516
Я кажется перестал понимать годот тред.
Это уже сингулярность годота или еще нет?
Суть проблемы в том, что ООП в Godot размазано между императивным GDScript и декларативным PackedScene/Resource. Ты можешь много чего создать в Godot, не создавая GDScript-скрипты, а только лишь создавая сцены .tscn и соединяя внутри них ноды и сигналы. Создавать сцены как .tscn удобно, потому что у тебя есть WYSIWYG редактор и удобный инспектор свойств. Альтернатива - создавать сцены из кода, что очень неудобно, ведь ты не видишь промежуточные результаты, и сложная сцена растягивается на много несвязанных строк кода. Поэтому, разрабатывая какой-то компонент для своей игры, программы или плагина, ты сталкиваешься с проблемой, когда тебе нужно создать экземпляр какого-то сложного класса, но этот экземпляр должен забрать с диска .tscn файл и создать экземпляр сцены, иначе он не будет полностью работоспособен. Но как это сделать? Есть несколько разных путей, но Godot до сих пор не даёт однозначно лучший вариант. Приходится ломать голову над этим организационным моментом.
Вот простой пример: тебе нужен список сохранений в игре, который может увеличиваться и уменьшаться (разное число слотов), и каждое сохранение имеет иконку, название, дату сохранения, иконки и названия режима игры и прочую шаблонную информацию. Ты, естественно, создаёшь базовый контейнер через VBoxContainer в ScrollContainer, но дальше тебе нужна сцена-"слот сохранения". Ты создаёшь эту сцену-слот, и она у тебя имеет десятка два различных Control-нод с кучей настроек в инспекторе, которые ты бы замучился перечислять в коде GDScript, не видя того, каким получится результат. Дальше тебе нужен способ добавить сцену-слот в свой контейнер, когда игрок создаёт новое сохранение или когда игра сканирует папку сохранений и обновляет список сохранений на экране.
Самое очевидное решение будет:
>var save_slot_scene: PackedScene = load("res://gui/save_slot.tscn")
>var save_slot: Control = save_slot.instantiate()
>save_slot.data = save_data
>saves_list.add_child(save_slot)
Но это куча строчек для БАНАЛЬНОГО действия "создать объект, заполнить данными и сунуть в дерево".
В идеале, ты бы хотел что-то вроде такого:
>saves_list.add_child(SaveSlot.new(save_data))
Просто и понятно, не так ли? Мы добавляем в список свежесозданный слот с указанными данными. И нас не волнует, откуда с диска всё это считывается, как инстанциируется и куда там внутри помещаются наши данные - мы используем принцип инкапсуляции из ООП и поэтому код простой и понятный... вот только Godot препятствует так делать.
Да, можно перезагрузить _init() и добавить в него любые аргументы, но если ты добавишь аргумент в него, то ты уже не можешь добавить свою ноду в дерево сцены через ctrl+A, если у аргументов нет значений по умолчанию. Ладно, добавил, создал сцену, сохранил в .tscn... а как/когда теперь грузить её с диска? В момент вызова new()? Или когда будет уже _ready()? Но если эта нода потребуется снаружи до того, как она готова... и как вообще добавить в НОДУ заранее подготовленную СЦЕНУ, если у СЦЕНЫ на диске обязательно должна быть одна корневая нода? То есть у нас получается два корня: один создаётся new(), другой мы хотим считать из .tscn и поместить в дерево... Но мы не можем вернуть ссылку на .tscn через new()... Мы можем только создать свой статический метод, возвращающий экземпляр загруженной сцены. Но он не может называться new(), потому что такой метод невозможно вызвать.
> Суть проблемы в том, что ООП в Godot размазано между императивным GDScript и декларативным PackedScene/Resource.
Эммм... Нет. Пакед сцены/ресурсы - это сериализация. Не имеет прямого отношения к ООП.
> Ты можешь много чего создать в Godot, не создавая GDScript-скрипты, а только лишь создавая сцены .tscn и соединяя внутри них ноды и сигналы. Создавать сцены как .tscn удобно, потому что у тебя есть WYSIWYG редактор и удобный инспектор свойств.
От тебя спрятали под капот создание инстансов, от этого ООП никуда не размазался.
> В идеале, ты бы хотел что-то вроде такого:
> >saves_list.add_child(SaveSlot.new(save_data))
> Просто и понятно, не так ли? Мы добавляем в список свежесозданный слот с указанными данными. И нас не волнует, откуда с диска всё это считывается, как инстанциируется и куда там внутри помещаются наши данные - мы используем принцип инкапсуляции из ООП и поэтому код простой и понятный... вот только Godot препятствует так делать.
Нет, не препятствует.
Дальнейший текст вообще не вижу смысла комментировать там каша дичайшая из терминов и концепций без понимания сути.
А суть в том, что если ты хочешь из кода одной строчкой добавлять десериализованные объекты в дерево, то просто инкапсулируй вышеуказанные тобой же длинные строчки десериализации в один метод, который и вызывай.
>var save_slot_scene: PackedScene = load("res://gui/save_slot.tscn")
> ...
>func get_slot(slot_data: Resource) -> Control:
>____var save_slot: Control = save_slot.instantiate()
>____save_slot.data = slot_data
>____saves_list.add_child(save_slot)
>____return save_slot
> ...
>saves_list.add_child(get_slot(save_data))
За сериализацию приходится расплачиваться в коде вот такими вот функциями-обёртками.
То, что ты описываешь, называется отложенная инициализация. Именно поэтому стадия instantiate() и add_child() разнесены. Может быть, разраб хочет только создать сцену, что-то рассчитать, а добавлять ее только тогда, когда какой-то юнит выстрелит пулькой. Поэтому, это так и выглядит
var a = obj.new()
...
obj.config(params)
...
add_child(obj)
А вот как раз если ты слепишь все в один вызов new(), то тебе надо знать все параметры заранее
>Т.е. я заранее понимал, что это должно быть неправильно, но ожидал, что IDE предупредит или Godot крашнется. Но нет...
Вероятно, с точки зрения языкового сервера, ты можешь создать функцию new потому, что её не существует в GDScript. Это надстройка на уровне парсера, алиас, который выделяет под объект память и вызывает init(), ближайшая аналогия - оператор new в С++.
> func do_some():
> ____ #do some
> ____ return self
и тогда вообще преисполнишься как тот идущий к реке.
Будешь хуярить конвеерный код как профи:
> var obj = MyObject.new().confgure(ObjectData.new().sync(SaveData)).reload().hide()
> >var save_slot_scene: PackedScene = load("res://gui/save_slot.tscn")
> > ...
> >func get_slot(slot_data: Resource) -> Control:
> >____var save_slot: Control = save_slot.instantiate()
> >____save_slot.data = slot_data
> >____return save_slot
> > ...
> >saves_list.add_child(get_slot(save_data))
Да вы правы, это нейронка насрала, щас приберу, а пока что прослушайте рецепт черничного пирога.
>Нет, не препятствует
>приходится расплачиваться
Сам себе противоречишь в одном посте...
>сериализация не имеет прямого отношения к ООП
>От тебя спрятали под капот создание инстансов
Ты не понимаешь. Godot выше по уровню абстракции...
>>1105537
>Может быть, разраб хочет только создать сцену...
Ты, похоже, тоже не понял, о чём речь идёт. Вот здесь:
>obj.new()
Уже ожидается "создание сцены", целиком и полностью (все ноды). А это:
>obj.config(params)
Делает САМ ДВИЖОК, когда ты делаешь load("scene.tscn").instantiate().
>>1105538
Да какая разница. Юзер может допустить ошибку - юзера нужно предупредить...
>>1105540
Я пробовал так делать - мне не понравилось. Слишком неудобно выглядит...
>>1105543
Неудобно, что кто-то думает и пишет больше тебя? К школе готовься.
> Ты не понимаешь. Godot выше по уровню абстракции...
Нет там ничего принципиально отличающегося от остальных тулкитов и фреймворков, которые десериализуют сериализованные ранее через редактор данные, формы/объекты/конфиги/сцены, да что угодно. Как это я не понимаю-то? Да как же я не понимаю-то после 20 лет в формошлёпстве?
Между TSCN и модным нынче XAML нет фундаментальной разницы, только язык другой. А разница исключительно в глубине запрятывания от тебя процесса создания нового инстанса, прохода парсером по файлу, и заполнения полей инстанса данными из файла.
... в том числе, если работа парсера предполагает создание отдельного дерева, создание инстансов и добавления их в дерево, это абсолютно ничего не меняет.
Если ты полез в DI
-Во первых надо смериться что будет много ручного бойлерплейта. Но оно того стоит, если проект будет больше змейки.
-Модуль у тебя всегда сцена - внутренние скрипты сцены не модули, инжектить в них не нужно, только в главный скрипт модуля (owner).
-Не использовать (никогда даже для extends RefCounted) базовый конструктор _init().
- Придумать свой "конструктор" модулей - я предлагал имя setup().
Проверять на вызов не нужно, если забыл дернуть его - все нуллами посыпиться и так.
-Тебе придется держать сервис локатор, иначе ты сума сойдешь когда игрока будешь просовывать через 3-4 модуля. Локатор лучше использовать глобальный класс. Да можно и в Main держать - но тупо просто удобнее
Насчет метода-конструктора setup - это самый правильных подход. Покажется избыточным пробрасывать туда, особенно когда больше 5 зависимостей. Но в реале тебе гдискрипт не даст что-то забыть передать (модуль либо работает либо нет, не будет какой-то магической баги, когда null дернет в середине игры).
Всем кто планирует проекты на годы вперед, рекомендую DI - нудятина, но потом увидите - что даже открывая модуль вы будете видеть по setup - от чего зависит модуль который вы написали годы назад (его контракт зависимостей).
>Тебе придется держать сервис локатор, иначе ты сума сойдешь когда игрока будешь просовывать через 3-4 модуля. Локатор лучше использовать глобальный класс.
Можно еще группы юзать, вместо сервис локатора. Только средствами движка (а не кодом задавать) иначе там может быть хрень с _ready. Но мне проще синглтон.
> Тебе придется держать сервис локатор
Синглтон! Синглтоооон!
Нет, ты не понимаешь. Если ты на Delphi/Lazarus/какой-то похожей RAD IDE сделаешь новый компонент, он будет компилироваться в саму IDE и использоваться как родной. В Godot такое поведение возможно только если ты сам, своими руками, спавнишь все нужные тебе ноды в дерево сцены (именно через код, а не через редактор - это очень важное отличие, нужно держать это в голове). Для этого даже есть концепция "internal nodes", что не отображаются в дереве сцены и по умолчанию не выдаются функцией get_children(). По-хорошему, так и надо делать...
Но Godot выше по абстракции, чем простые формошлёпалки, и тебе часто нужно МНОГО разных мелких нод, которые нужно по отдельности настраивать, и подгонять все эти настройки без визуального редактора сложно. А визуальный редактор не генерирует код на GDScript, он может только сохранить сцену как tscn/scn, и всё. То есть твой "новый компонент" разрывается между скриптом "что делать" в .gd и скриптом "как выглядит" в .tscn. И ты вынужден выбирать: либо загружать сцену по пути в файловой системе и надеяться, что по этому пути файл всё-таки есть и он нужного тебе класса, или как-то прикручивать .tscn внутрь .gd, чтобы обращаться по имени класса через базу данных классов. Это создаёт лишнее трение, разве непонятно? ...а ещё не забывай, что у .tscn есть своя иерархия и композиция, что живёт отдельно от скриптов, и поэтому их следует рассматривать как отдельную ООП систему, что вводит путаницу.
Поэтому хочется, чтобы new() могла возвращать не одну ноду, а целую сцену, которую движок прочитает с диска:
>@scene("my_complex_class.tscn")
>class_name MyComplexClass
>extends BaseClass
Здесь строчка "@scene()" должна указать Godot, что для работы этого класса необходимо сначала прочитать данные в указанном файле и создать все ноды, а только потом - вернуть экземпляр. Или даже проще, если указан тег @scene, тогда Godot автоматически ищет файл имя.tscn рядом с файлом имя.gd, без указания пути до файла (ведь очевидно, что такой скрипт будет лежать в одной папке с тем же именем, что и файл сцены, т.к. он с ней связан).
Вот здесь можешь почитать ещё: https://github.com/godotengine/godot-proposals/issues/1935
Пруф того, что люди на это наматываются: https://github.com/godotengine/godot/issues/113596
>>1105556
>Если ты полез в DI
Какое отношение эта проблема имеет к DI? У тебя только DI на уме?
>будет много ручного бойлерплейта
Проблема не бойлерплейте, а в том, что ты юзаешь что-то вместо new() с ролью new(), а new() ломается.
>Модуль у тебя всегда сцена
Это тоже не имеет отношения к теме. "Модулем" может быть и всего одна нода - сцена не обязательна.
>Не использовать (никогда даже для extends RefCounted) базовый конструктор _init()
Это вообще какая-то шиза. Почему нет? Тем более для RefCounted... Нет, _init с аргументами - это база.
>конструктор... setup()
Семантически, "setup" - "настройка (того, что есть)", например "set up computer" - "настроить компьютер" (а "computer setup" - это "(уже) настроенный компьютер"). Конструктор в ООП является создателем экземпляра по заданным шаблонам/чертежам (называемым обычно "классами"), поэтому для конструктора больше подходит имена типа "construct", "create", "build", "make", "new" и т.п. У нас в GDScript уже есть "new", поэтому логично его перезагрузить... но не получается...
>придется держать сервис локатор, иначе ты сума сойдешь когда игрока будешь просовывать
Задолбал со своими сервисами. Если у тебя нет сервисов, то не нужно их и искать. Зачем ты куда-то игрока "просовываешь"? Мобам, например, не нужно ничего об игроке знать, пока Area не коснётся, а там они и сами разберутся, кого и где увидели. У тебя просто какая-то профдеформация с этими сервисами, которые ты постоянно хочешь куда-то куда не нужно просунуть. Об игроке большинство игровых сущностей знать не должно абсолютно ничего, как будто игрока и не существует...
>>1105558 >>1105559
Да вы даже игр не делаете, на что вам эти синглтоны?
> Нет, ты не понимаешь.
Да уж куда нам.
Умничка. Не спорь с большими дядями.
Страшно, но в реале можно и его выкинуть, в Main все сервисы положить.
Если есть main. Знать об игроке, знать о текущем мире - это как раз область ответственности главной ноды.
Я кодить начал лет 20 назад, почти сразу в контексте важных для видеоигр тем.
>>1105566
Ты превращаешь свой main в глобальную свалку данных, а в этом 50% вреда синглтонов.
>Знать об игроке, знать о текущем мире - это как раз область ответственности главной ноды.
Зависит от игры, конечно, но обычно - нет, главная нода не должна знать о мире и игроке.
Вообще. Обычно игрок знает больше всех, ибо это точка взаимодействия с игроком.
>Проблема не бойлерплейте, а в том, что ты юзаешь что-то вместо new() с ролью new(), а new() ломается.
У тебя обострение, прими что ПНД прописали.
Я пытался понять что за бредовый поток мысли, возможно ты путаешь два мира - мир дерева нод и мир кода?
Это все ваше компонентная разработка - она тебя и свела с ума.
Хватит воспринимать скрипты - нодами.
Модуль у тебя только сцена.
Родитель сетапит всех детей, даже если это не сцены.
new() - занято, придумай свое инициализирующий метод.
Синглтон - это нормально. Но если ты коснулся DI - то выкинь.
Сервисы - удобнее отлаживать чем сигналы. Но сигналы нужны.
Небо - синие
Трава - зеленая
Все.
> Зависит от игры, конечно
Если мне позволит сравнения уважаемая модерация, но в Unreal Engine именно так, как тебе выше взрослый дядя расписал. И ничего. Как то пишутся там ААА тйтлы.
>У тебя обострение
>бредовый поток мысли
Если мне не веришь, то хотя бы по ссылкам пройдись:
https://github.com/godotengine/godot-proposals/issues/1935
https://github.com/godotengine/godot/issues/113596
И там дальше другие, много их. Не я один такой.
>>1105571
>но в Unreal Engine именно так
Мог и не говорить - смотри пикрил и делай выводы.
>Ты превращаешь свой main в глобальную свалку данных, а в этом 50% вреда синглтонов.
Проблема синглтонов вообще не касается геймдев разработки. Хз откуда эти пугалки, у тебя не будет никогда смены контекста, даже юнит тесты не пишет никто.
То что локатором будет main - не делает его god object. God object - это про другое.
Так что нет проблем если главный класс отвечает за все сервисы в игре. Главная ошибка - если ты будешь из сцен (других модулей) добавлять внутренние "кишки" в main.
Почему я выкинул синглтон - потому что стал писать общую библиотеку для всех тайловых игр. И стал выносить код для юнит тестов. Кто тут вообще пишет юнит тесты в играх?
>Не я один такой.
Годот просто испещрен WTF-решениями. Приходиться только адаптироваться.
Я говорил что организация модульного кода ппц как сложна.
Что мешает?
const MY_SCENE = preload("uid://fsdfsfsdfsf") // наш модуль
var my_obj := MY_SCENE .instantiate()
my_obj.setup(self, di1, di2, di3) // Инжектим все зависимости
add_child(my_obj)
Если у тебя просто скрипт лежит
var my_obj := MyClass.new()
my_obj.setup(self, di1, di2, di3)
my_obj.create_super_game()
Воспринимай new как оператор в шарпах, просто с другой стороны.
new MyClass()
Опять начинается...
>не касается геймдев разработки
Ммм, расскажешь потом, как искал односимвольную ошибку по всему проекту, из-за того, что не можешь отловить, кто и откуда насрал в глобальное хранилище данных ошибками, которые не крашат игру, но делают её работу некорректной с точки зрения реального пользователя... Хотя, если ты обмазался тестами, то до игры ты тебе ещё долго двигаться...
>откуда эти пугалки
Опыт, сынок, опыт - сын ошибок трудных...
>God object
При чём тут God Object, если речь про то, что любая мразь может бесшумно насрать в общий колодец?
>если ты будешь из сцен (других модулей) добавлять внутренние "кишки" в main
Они у тебя уже давно перепутались своими кишками, если делают что-то вроде:
>get_tree().service.foo(bar)
В рандомном месте проекта. Это нисколько не лучше "синглтона" (autoload).
>юнит тесты
Да что ты к ним прицепился-то? Вред в любом случае огромный.
>>1105582
>Что мешает?
Ничто не мешает, но хотелось бы больше так не делать... Выглядит просто ужасно.
>Ничто не мешает, но хотелось бы больше так не делать... Выглядит просто ужасно.
Выглядит логично (сцену надо с диска поднять и инстанцировать всю макаронину), а вот где реально бойлерплейт начинается - пик.
Чтобы внести одну зависимость надо три раза её прописать, еще в родителе прокинуть.
>Опыт, сынок, опыт - сын ошибок трудных...
Ну твою ошибку мы знаем, ты повесил одни данные в разных местах несвязанных местах. Это была даже не проблема синглтона, но ты не хочешь учиться и принять свою ошибку.
Ты в курсе что передача по ссылки несет в себе глобальное состояние?
Когда передаем юзера setup(user) мы не клонируем объект а передаем по ссылке. И поменяв
user.nick = "Ваня"
изменится везде глобально где ты передал user целиком.
Так что больше половины работают с глобальными состояними и в ус не дуют. Больше скажу - в игре нужно работать только с глобальными состояниями.
Игра никогда не будет масштабировать между нескольких машин - проблема глобального состояния игры не касается никак вообще.
Кто-то реально принес проблему из мира бэкенда и все долбятся об неё сейчас.
>Trail3D
Блин...
>>1105593
У тебя "инъекция" задом наперёд. Ты объявил public property, ты владеешь жизнью этого объекта - так зачем тебе какие-то дополнительные костыли? Просто делай player.map = map, и дело в шляпе. В твоём конкретном случае тебе никакой setup() вообще не нужен. Высосал из пальца и жалуешься.
>>1105592
>сцену надо с диска поднять и инстанцировать всю макаронину
Это детали имплементации. Сегодня - с диска, завтра - сгенерирую в RAM с нуля, послезавтра - буду вообще из интернета скачивать. В отличие от внешних зависимостей (DI), за внутренние штуковины вроде данных из .tscn должен отвечать сам объект, а не тот, кому он нужен в рабочем состоянии.
Пример для сравнения: есть инвалид на костылях и автомобиль в таксопарке. Костыли у этого инвалида должны быть изначально при нём, задолго до его выхода из квартиры, а вот автомобиль к нему снаружи подъезжает, потому что он позвонил в таксопарк и попросил подогнать подходящий автомобиль. Так что костыли - это детали имплементации (сегодня нужны, а завтра он здоров, а после завтра ему вообще кресло-каталка потребуется), а автомобиль как бы внедряется снаружи, но по запросу объекта, т.к. без автомобиля он не сможет добраться куда ему надо, но автомобиль его деталью не является. В нашем случае "запросом" является существование публичного свойства с null вместо нужного объекта, и мы должны присвоить ему то, что там требуется, тем или иным способом (лучше всего через инспектор). А вот как мы загружаем (и загружаем ли) сцену с диска - это нас беспокоить вообще не должно...
>изменится везде глобально где ты передал user целиком
Ты что-то путаешь. Глобальное состояние - влияющее глобально на всю программу в целом. Если совершенно любой твой объект может просто так, ни с того, ни с сего, написать Player.health = 0 и игрок умрёт, то твой Player - это глобальное состояние. Если 99.99% объектов должны сначала написать "а скиньте мне кто-нибудь ссылку на player, я хочу с ним кое-что сделать", и только потом они смогут внести изменение в его состояние, то это не глобальное состояние - это локальное состояние 0.01% объектов, запросивших и получивших ссылку на общий для их локальной группы Player.
Сравни это с переменными в классе. Если переменная в методе класса, то это, безусловно, локальное состояние конкретного участка метода класса. Если переменная в полях класса, то это "глобальное состояние для методов класса", но это "локальное состояние среди объектов приложения", потому что другие объекты не имеют прямого доступа к этому полю. То есть всё относительно, да, но когда говорят "синглтон - это плохо", подразумевают, в числе прочего, что ты светишь одной точкой на глазах у всех методов всех объектов одновременно, и все они одновременно имеют неограниченный доступ.
>не проблема синглтона
Зачем ты используешь строгую типизацию в GDScript (или даже C#/C++), зачем тебе какие-то паттерны ООП? Почему бы не использовать чистый ассемблер и менять биты и байты в памяти компьютера так, как тебе сегодня захочется, не думая о последствиях? Ты же можешь, я уверен, запомнить каждое своё действие и не допустить ни единой ошибки, какой бы сложной ни была твоя задача. Тебе не нужны все эти детские ограничения, сдерживающие творческий потенциал программиста. Так почему ты ещё не пишешь на ассемблере, а лучше - намагниченной иголкой на поверхности жёсткого диска?
Синглтон имеет две проблемы: он почём зря запрещает создавать копии себя, как будто ты случайно можешь создать копию и не заметить этого, но он также даёт полный и неограниченный доступ к определённым данным и функциям, как будто ты можешь гарантировать безошибочность всех своих действий. Только новичок без опыта будет отмахиваться и стрелять себе в ногу таким способом...
Скорее ты не понял. В Node.new() создается ненастроенная нона, потом у нее вызывается метод config или setup(param). Так на практике всегда и происходит. Инстанциируется сцена пульки. А потом менеджером ей задается ее глобальная позиция, вектор и скорость, цвет. Да пулька может вообще из пула переиспользуется, а не создается новая. Поэтому конфигурация это отдельный от создания шаг.
А так не бывает, потому что таксист приедет, увидит что там коляска, скажет места нет и уедет. Нужен менеджер, который знает о костылях, и он вызовет именно такси с местом под костыли.
>Просто делай player.map = map, и дело в шляпе.
Если я забуду вызвать setup - упадет практически сразу, потому что будут null
А если я буду полями инициализировать
1) Непонятно какое поле просто паблик, какое инъекция.
А я хочу видит условия - как использовать модуль - все его зависимости.
2) Если я инициализирую 5 полей, а 6 забуду и оно вызывается фиг пойми когда - я получу плавающую ошибку в середине игры. В случае setup я свалюсь сразу (я даже локальные сцене ноды там прописываю, поэтому упаду быстро).
>Пик
Если ты хотел сделать цепочку вызовов как на пикче, то ты можешь возвращать self.
>Много текста
Я не хочу спорить за DI это надо раз понять, что это. Оно даже помогает правильно ответственность распределить, когда сам не видишь (главное не передавать везде один main -а передавать именно сервисы/менеджеры. У меня main передает не как локатор, мне там надо получить позицию мышки от main).
Про глобальное состояние тоже спорить не хочу, там все правильно я написал. Хочешь реально увидеть локальное состояние - иди в раст с иммутабельными переменными и владением (ну или в любой ФП язык).
>Зачем ты используешь строгую типизацию в GDScript
Если честно только ради автокомплита. Пока не будет jit компиляции и из сорцев не уберут конвертацию в variant, особо не вижу смысла использовать (кроме циклов). Все узкие места (циклогонялки) я с тестами перепишу на С++, все равно гдскрипт поддерживает вложенность типизированных массивов только на 1 уровне.
Да я знаю про ту статью о 30%, не надо кидать ссылку.
>Если ты хотел сделать цепочку вызовов как на пикче, то ты можешь возвращать self.
Да что такое с пикчами.
Ладно, специально для тебя любимого сделал пример (пик, если не отвалится)
В реально разработке в DI передаются только интерфейсы (мы можем только абстрактные классы, что тоже самое).
А объекты передаются через полиморфизм. У нас появляются чистые объекты, на манер чистых функций (чистые функции - термин гуглиться).
Почему я постоянно ною за интерфейсы
Потому что нельзя сделать такое
>class Ежик extends IМожетХодить, IМожетЕсть, IМожетВзаимодействовать, IМожетЛетать
Почему они добавили абстрактные классы, а интерфейсы не добавили я хз.
>Игра никогда не будет масштабировать между нескольких машин - проблема глобального состояния игры не касается никак вообще.
У тебя не будет - поэтому тебе плохие практики не мешают.
Любой функционал - типа реплеев, мультиплеера, банально рассчет ходов наперед - требует дублировать мир.
Клиент игры будет всегда только на одной машине.
может когда игры будут только в облаках и клиенты надо будет масштабировать.
Проблема серверного мира, если есть глобальное состояние.
клиент - запрос - сервер А - сессия (одни состояния)
через минуту
клиент - запрос - сервер Б - сессия (вообще другие состояния)
Потому что они идут на поводу ноющих перекатунов на форумах, и добавляют фичи, которые СКРИПТУ(!) не нужны. И абстрактные классы не нужны, и аннотации, и явная типизация, и ещё куча фич, которые они понавводили. Они забыли, для чего был нужен скрипт: легкая автоматизация для непрограммистов.
Для жёсткого кодинга всей игры нужен был отдельный полнотьюринговый язык. Они всунули туда шарп. Я с этим тоже не согласен. Нужно было сделать свой собственный GDLang, в котором были бы и абстракты, и интерфейсы, и лямбды, и типизация, и всё остальное, о чём ноют на форумах. Таким образом было бы чёткое разделение: либо создаётся файл скрипта, который является ресурсом в обьектной системе, подцепляется к скриптам, прост и понятен новичкам; либо создаётся файл компилируемого модуля, результатом компиляции которого является полноценная нода в объектной системе движка. Как в GDExtension, только прямо в редакторе, без сторонних IDE и фреймворков, все целевые DLL компилируются при экспорте в целевую платформу, либо вшиваются в экспортный wasm, совместимость полностью независима от сторонней платформы (как в случае с шарпом).
И этот GDLang уже мог бы выглядеть более профессионально, без оглядки на новичков:
> class Ежик inherits Mammal implements IМожетХодить, IМожетЕсть, IМожетВзаимодействовать, IМожетЛетать
Да им и сейчас нужен такой язык.
По хорошему неплохо было иметь два мира как во фронтенде.
Базовый js где все еще можешь указать типы для IDE через jsDoc и ts - для хардкора с компиляцией, дженериками и шлюхами интерфейсами (правда ts компилится в js, что тот еще мир абсурда).
Нельзя просто добавить типы и сказать - дальше сами епитесь как хотите. Если полез в эту область - долбись до конца. Но в реале мы долбимся в кадре, а в кадре мы можем долбиться в списки. В общем, для геймдева перебирать динамические типы налету - кажется плохим решением всегда. И зачем делать ставку на новичков, которые отваляться завтра - непонятно.
Что касается шарпов, то он там смотрится криво, как не родной. Плюс еще два сборщика мусора сверху вылезают (а ты даже одному не рад).
Но уже ничего не поделать, мы слишком избалованы gdscript
> Но уже ничего не поделать
Мир несовершенен, постоянно такое наблюдал всю жизнь, простое и очевидное решение всплывает, когда годы потрачены на развитие и поддержку хуйни. И потом включается принцип трамвая: ты можешь повернуть рычаг, но тогда, но тогда.
>Да им и сейчас нужен такой язык.
Хотя я сейчас подергал ИИшку и она говорит что у плюсов будет минимум оверхеда на GDExtension C++.
>Да им и сейчас нужен такой язык.
В общем, такой язык у годота есть - это С++
Ну и не забываем что у нас есть сорцы, мы можем нагадить прям в движок без оверхедов. никто этого делать не будет, но максималисты могут спать спокойно
>Мир несовершенен, постоянно такое наблюдал всю жизнь,
Это проблема разработки снизу вверх. Когда ты пишешь практичный код, потом рядом еще, еще и когда оглядываешься оказывается что уже склад костылей.
Но ты тоже не можешь сразу сделать идеальное API, только с оглядкой на опыт. К версии Godot 17 все сделают.
> К версии Godot 17 все сделают.
Но жить в эту пору чудесную уж не придётся ни мне, ни тебе.
В общем, я так покапал и оказалось это прям не рокет сайнс и делается не сложно. Что касается затрат, если дублировать классы в С++ (скажем получать свойства не через Variant, а по средствам каста в существующий С++ класс), то выходит тоже не дорого.
В теории, можно даже GDScript -> C# если в числодробилке не дергать вызов API движка.
>Пик3
НО оказалось годот работает с пакетными массивами почти прозрачно между GDSript и С++. Этакий ECS поневоле получается. Так что с учётом того что вызов API у GDSript дешевый и все данные на дробилку завернуть packed - связка GDSript и С++ получается убер мощная (но надо тестить).
То есть, если делать свою ECS систему, то только на связке GDSript и С++, причем у тебя уже есть пакетные массивы.
А у шарпов есть накладные расходы на интероп/маршалинг между шарпами и API.
опять с++ учить, в 20 раз
Безумие! Пакетные массивы это даже не спец-классы, это просто алиасы С++ векторов (списков).
Живите с этим!
> а по средствам
Посредством. Проверочное слово посредник (а не средства).
двач образовательный
> опять с++ учить, в 20 раз
В конечном итоге мы все выучим кресты (а потом и чистый си).
Все эти шарпы, жавы, дельфи, питоны - полумеры, жалкая попытка лентяя отсрочить неизбежное.
>двач образовательный
Нет времени внимательно перечитывать свои посты. Пока ты думаешь, кто-то уведет твой далб или трипл!
>Так это было в треде еще года 4 назад сказано.
Цивилизации исчезают, а исследователи будут всегда
Там есть какой-то подводный, я до конца не разобрался, внутри гдскрипта packed-arrays передаются по ссылке, а вот между gdextension и gdscript по значению, а вот дальше я не копал, то есть там заявлено copy on write, но это может значить, что при изменении одного элемента, все равно весь или большая часть (несколько кб) массива будет переписываться.
Мало нарыл про это, может где-то еще найдется
https://forum.godotengine.org/t/gdscript-to-c-pass-packed-array-by-reference/81446/2
https://forum.godotengine.org/t/returning-a-packedbytearray-from-a-gdextension-class/83300
https://github.com/godotengine/godot-proposals/issues/10830
Кстати, да.
Vector<float>
это не тоже самое что
std::vector<float> из стандартной библиотеки C++.
Это свой список:
https://github.com/godotengine/godot/blob/master/core/templates/vector.h
И дальше надо смотреть на CowData<T> из
include "core/templates/cowdata.h"
COW - аббревиатура как раз переводиться как Copy On Write
Но на сегодня хватит С++, главное во время остановиться
>COW
Музыкальная пауза
https://www.youtube.com/watch?v=kk3_5AHEZxE
>увидит что там коляска, скажет места нет и уедет
Демагогия... Менеджер таксопарка = программист.
>>1105603
Опять ты какую-то чепуху несёшь.
>В Node.new() создается ненастроенная нода
Настроенная, если ты настроишь через _init().
>Инстанциируется сцена пульки. А потом...
"Инстанциация сцены" - это в т.ч. "настройка".
>>1105605
>упадет практически сразу, потому что будут null
Модульный проект не должен падать, т.к. модули по определению сущности автономные - способны по отдельности существовать, без инъекций, но будут бездействовать в некоторых ситуациях (как когда отсутствует карта для поиска пути для движения).
>какое поле просто паблик, какое инъекция
Что такое "просто паблик"? Просто дырка какая-то, существующая без цели, без предназначения? Опять демагогия - "Что если я создал поле и не знаю, зачем создал, как я узнаю, что оно мне зачем-то нужно".
>инициализирую 5 полей, а 6 забуду
Если твой Player требует одновременно шесть (!!!) независимых инъекций, то это уже труп, и не нужно заниматься некрофилией, просто закопай его и иди нормальную архитектуру проектировать.
Скорее всего, твои шесть независимых инъекций одновременно относятся к одной и той же области конкретного проекта или пусть даже к двум (world, отвечающий за физический мир и всё, что в нём теоретически может существовать, и GUI), так что, предоставляя к ним доступ, ты просто затягиваешь клубочек потуже. Нужно реверсировать контроль и принуждать игрока ЯВНО взаимодействовать с его окружением, а не давать ему кольцо всевластия.
>спорить не хочу, там все правильно я написал
Ты просто упёртый как школьник...
>Если честно только ради автокомплита
Смысл строгой типизации в том, чтоб в коде не было неуловимых ошибок, когда ЯП неявно конвертирует требуемые данные в какой-то неожиданный формат. Неявность - главное зло, и глобальное состояние - это главный источник неявности в коде. Потому что когда происходит взаимодействие с глобально доступными ячейками памяти, это неявно действует на тысячи неоднозначных позиций в коде, хочешь ты того или нет, знаешь ты об этом или нет (в сложном проекте).
>демагогия
>чепуха
>упертый школьник
Выглядит так, что аргументов у тебя нет, и ты просто пытаешься "победить" в споре токсичностью, сделав его неприятным для остальных участников, чтобы они перестали тебе отвечать и таким образом за тобой останется последнее слово и ты якобы от этого становишься прав.
>сделал пример
Лол, а почему не сделал так?
>class Машина:
>_ func move(how: Привод) -> Машина: how.how(); return self
И тогда ты мог бы собрать такую шизу:
>Машина.new().move(Колёса.new()).move(Лыжи.new()).move(Гусеницы.new())
В одну строчку - твоим любимым конвейером.
Я это к чему? Твой пример - слишком абстрактный, оторванный от реальной жизни. В реальной жизни в большинстве случаев ты не нуждаешься в подобном переобувании на каждом шагу, а если даже внезапно потребуется переобуться, тебе нужен reset()/clear(), сбрасывающий/очищающий состояние объекта к изначальному, а не просто setup(), потому что своим переобуванием ты можешь создать неожиданное состояние... Типа если твои "колёса" повёрнуты на 45 градусов, а у гусениц поворота нет, и теперь вездеход двигается строго по диагоналям, и ты потом можешь придумать костыль "после установки гусениц нужно запустить 1 гусеницу на 3.5 секунды и дождаться разворачивания на -44.9999456789 градусов"...
В реальности ты используешь то, что тебе удобнее.
>>1105615
>Потому что нельзя сделать такое
Они планировали добавить Traits в GDScript, но это оказалось слишком сложным на текущей базе, и они переделывают GDScript с ClassDB на GDType, чтобы разрешить все эти проблемы. Когда переведут на этот GDType, тогда и реализуют тебе эти Traits. Ждём.
>>1105672
>фичи, которые СКРИПТУ(!) не нужны
Если тебе нужен огрызок из игр 00-х - можешь сам реализовать и использовать. Это совсем нетрудно (разрабатывал свой скриптовый язык за пару дней).
>Нужно было сделать свой собственный GDLang
>все целевые DLL компилируются при экспорте
Зачем второй ЯП, если GDScript компилируемый?
>уже мог бы выглядеть более профессионально
Самый профессиональный ЯП - Python/Cython...
>>1105681
>Нельзя просто добавить типы и сказать...
Школьник, Godot - некоммерческий проект. Хочешь свистоперделку - делай сам, не можешь сам - иди и задонать, чтоб наняли того, кто сможет сделать. Если посмотреть на историю всех старых языков и т.п. - то большинство постепенно набирали функционал, не рождаясь из вакуума сразу с миллионом багофич. Типизированные языки были до ООП/объектов, это совершенно независимые концепции информатики.
>>1105688
>минимум оверхеда на GDExtension C++
Насколько я это всё понимаю, из-за того, как сегодня GDScript/ClassDB устроен, GDExtension не оптимален. Имеются предложения вынести GDScript из движка и превратить его в компилируемый язык... но тогда утрачивается где-то 50~75% киллер-фич GDScript. Но окончательного решения до начала Godot 5 не будет.
Алсо, помни: LLM чатботы основывают все свои предположения на информации, доступной онлайн, а собирается эта информация с разных форумов, где школьники срут своими предрассудками, а также с официального гитхаба, где часто бывают смутные предположения и фантазии контрибуторов о том, как замечательно будет в гипотетическом будущем, если мейнтейнеры соизволят принять их слоп-реквест... Соответственно, доверия к LLM на тему Godot даже поменьше, чем на тему каких-нибудь ИРЛ событий. Фактически ты спрашиваешь у кривого зеркала, что отражает выдумки фантазёров с умным видом.
И да, мы (постеры ИТТ) тоже часто заблуждаемся.
>>1105736
>таким образом за тобой останется последнее слово и ты якобы от этого становишься прав
Ты про эту фразу говоришь: >>1105605
>спорить не хочу, там все правильно я написал
? Согласен, довольно глупо, словно в детском саду.
>токсичностью
Какая же ты снежинка, если даже тут "токсичность"...
Но ты прав в том, что я в плохом настроении сегодня.
>Модульный проект не должен падать, т.к. модули по определению сущности автономные
С чего вдруг? Что за бредятина. Модуль который фулл автономен - не несет сайд эффекта, а значит бесполезен (как программа, которая не исполняется).
Отличие модуля от лапши - минимальная точка входа и контракт - пик.
>Что такое "просто паблик"?
Публичное свойство (публичное API класса), которое не является контрактом инжекта. Неожиданно - родительский скрипт - owner - очень выгодно делать контекстом для всех остальных скриптов в сцене/модуле.
>Просто дырка какая-то, существующая без цели
Дырка у тебя в голове. С пропертями (сахар над геттерами и сеттерами) проблем инкапсуляции уже не существует (разве только в старой джаве без Project Lombok).
>Школьник, Godot - некоммерческий проект.
Язык тесно интегрируется со средой - совершенно нормально хотеть и требовать фичи. Ты потребитель, а не фанбой на страже веры, хватит технологи возводить в догму. Мы все тут с годотом работаем и хотим только лучшего, потому что буквально сами этим пользуемся. Поэтому не путай движкосрачную критику от нытья по фичам (у тебя контузия от движкосраника, ты взрываешься по любой херне).
>Имеются предложения вынести GDScript из движка и превратить его в компилируемый язык... но тогда утрачивается где-то 50~75% киллер-фич GDScript
Каких? У тебя твой язык - ты волен делать любую магию (сильно насрать в ключевые слова уже не получится, но @аннотации бесконечны).
Ничего не будет, станет только лучше. Надо просто выкинуть variant (о чем скажут спасибо все типизированные языки) и сделать JIT cо спекулятивной оптимизацией (тогда другие типизированные языки станут не нужны). Но это невероятно много работы, как минимум годот 17 (или годот 9 если китайцы помогут).
Сейчас по сути кроме packed массивов в гдсрипте ничего нет, типизация поверхностна.
А прикинь было бы круто анонсировать свою структуру и поместить потом в упакованный массив структуры - тебе тогда вообще не нужно С++ и эта шляпа сразу закинеться на кэш процессора.
@struct MyStruct:
var v1: int
var v2: float
var mypack: PackedArray[MyStruct] = ....
И у тебя в памяти:
[MyStruct][MyStruct][MyStruct][MyStruct]
Вместо:
[ptr][ptr][ptr][ptr]
ptr - указатели, не могу имя со звездочкой написать
>Если твой Player требует одновременно шесть (!!!) независимых инъекций,
Это правда может говорить о том что модуль на себя много берет. Но когда у тебя все на мелких сервисах (Трейтах/Компонентах - то есть агрегации) это может быть нормальным.
Чтобы нам спорить надо понимать что у нас разные концепции организации кода
У тебя на сигналах.
У меня на сервисах/менеджерах.
>Ты просто упёртый как школьник...
Зло разрушает тебя.
>Смысл строгой типизации в том
Да все это знают, неожиданно динамическая типизация требует большего скилла и ответственности. Но мы можем получить мета-программирование на базе утиной типизации (там вообще разрыва мировоззрения - но отстрел всех конечностей).
Это все очень сложно и круто наверное, но если я просто хочу порисовать в блендере комнатки и походить по ним, то какой годот брать чтобы было попроще? Встроенный движок блендера сломал мне мозг питоном и нодами, я не очень умный, я люблю рисовать а не программировать!
>Они забыли, для чего был нужен скрипт: легкая автоматизация для непрограммистов.
Об этом и взрослый питон уже забыл, не? Зачем программистам думать о непрограммистах...
Бери последнюю версию.
А так мы все ждем годот v17.0.1
Читай доку, используй ИИ для обучения. Пытайся понять что делает каждая строчка кода. Через полгода-год (10 лет) будешь конвейром игры делать.
>я не очень умный
Мы все тут такие
Дорогу осилит идущий.
За ручку никто не водит.
>я люблю рисовать а не программировать!
Ты не поверишь, но у тебя больше шансов сделать игру, чем у программиста, которому с трудом дается рисование.
>пик
Все думают это жопа, а я рисовал торс. И как с этим жить?
У меня от картинки бугуртец небольшой, да, типы не существую на уровне процессора, но нужный для проверок на ошибки и задания размерности, чтобы не занимать лишнюю память.
>типизация требует большего скилла и ответственности
закручивание шурупа отвёрткой, а не шуруповёртом, требует большего скилла и ответственности
С такими вводными, все версии годоты для тебя можно считать одинаковой сложности
>неожиданно динамическая типизация требует большего скилла и ответственности
А зачем она вообще нужна в реальных задачах? Вот по-хорошему нужна? А не просто сэкономить на ручном касте числа в строку и обратно и создать кучу капканов нубам.
Я не ту картинку скопировал.
Суть:
Была раньше такая тенденция, люди начинали с пхп, жс, питонов и прочего. Откровенно говнокодили. Потом под давлением стигматизации или же просто ради развития попадали в "статик" языки, от чего просвещались и в корню меняли мнение. Тут ты реально начинал мыслить по другому и менялось все мировоззрение (в лучшую сторону).
Но с опытом, не малым опытом, когда ты уже понял многое, ты снова так или иначе касаешься динамических языков - и у тебя происходит новое озарение. Ты как бы уже не говнокодишь, не пытаешься пропихнуть собаку где нужен паровоз и в целом пишешь код модульно и структурированно, но оперируешь уже не типами, а целой системой абстракций и данных (по сути пишешь уже чистую логику как на DSL языке). Ты минуешь просто ворох бойлерплейта, которого ты писал раньше, но ценной того что тебе нужно многое держать в голове и нужно быть более внимательным.
Аналогия для понимания.
Ты первые взбираешься на гору без снаряжения, терпишь неудачу. Во второй раз ты идешь в экипировке. В третий ты понимаешь что экипировка решает и нагружаешься все больше и больше - и в целом доходишь до такого момента, что весь обвешан прагматичными штуками, но идешь крайне медленно - зато каждый шаг продуман и безопасен.
А потом, с опытом, ты выбрасываешь снаряжение, оставляешь нужное и идешь налегке. При этом у тебя достаточно опыта чтобы идти спланированно и безопасно, ты знаешь как действовать и тебя ничего не тяготит. Ты вдруг осознаешь насколько таже задача стала легче, но и все равно осознаешь риски такого похода.
>А зачем она вообще нужна в реальных задачах?
Быстро прототипириуешь.
Пробуешь фишки
Двигаешь, играешь, поворачиваешь.
Налету меняешь целые концепты.
Находишь нужное
Делаешь рефакторинг всего кода.
После архитектурного рефакторинга расставляешь типы
Доводишь до рабочего состояния.
Видел как рисуют художники новые образы? Не повторяют по рефам, а именно из головы? Они рисуют быстрые кривые скетчи, один, два, три... Бывает так что один вдохновляет на другой. Потом находишь нужное - начинаешь обводить линиями (лайнап) получается чистый креативный монстр из твоей башки.
Это такой же подход.
>Двигаешь, играешь, поворачиваешь.
Ой, зря я такую метафору написал. Сейчас придет кто-то кто это буквально понял и покажет как двигать и поворачивать объекты без прототипирования.
А почему для этого нужна обязательно динамическая типизация?
Нет, не обязательно динамическая типизация. Это вполне может быть вывод типов компилятором. На уровне написания кода ты разницы не видишь, но она есть. Компилятор не пихает варианты, а прописывает конкретный тип, а затем анализируя код далее, переписывает тип, и в итоге на вором проходе компиляции сразу ставится нужный тип. Отличие незаметное, но есть: требование обязательной инициализации переменных.
> var a # динамическая типизация
> var a = 10 # и динамическая типизация и выведение типов
> a = 20; a = "foo" # при динамической типизации не вызовет проблем, при выведении типов выдаст ошибку, потому что тип уже был назначен неявно
> a = 12.34 # при динамической типизации просто заменится тип, при выведении типов тип везде заменится на float на этапе компиляции и соответственно, всё что ты ранее в том же коде писал и считал как целые, будет считаться как дробные (10+20 будет 10.0+20.0)
>Модуль который фулл автономен - не несет сайд эффекта, а значит бесполезен
Ты - автономный человек: дышишь, питаешься, занимаешься метаболизмом. Но ты можешь объединиться с другими такими же автономными людьми в компанию, создав юридическое лицо, которое действует как одно целое, несмотря на то, что в его составе могут быть тысячи заменимых людей. Каждого человека можно отправить в оплачиваемый отпуск и не беспокоиться, что он умрёт с голоду без сиськи компании. Вот этот человек - это модуль в нашем контексте, хотя тут больше всего подходит термин "агент", но из-за ИИ слово "агент" теперь прочно ассоциируется с "ИИ-агентом", что немного из другой оперы (хотя и подходит по смыслу: ИИ-агент должен быть автономен, чтобы считаться агентом).
>Неожиданно - родительский скрипт - owner - очень выгодно делать контекстом для всех остальных скриптов в сцене/модуле.
Ты издеваешься? Перешёл на жирный троллинг? Сколько раз повторять, что "все остальные скрипты в сцене" НЕ ДОЛЖНЫ обращаться к owner/get_parent() и дёргать его свойства и методы. Если ты так делаешь, то ты завязываешь код в тугую лапшу, как если бы писал всё в одном файле в одном классе. Нафига тебе ООП, если ты им не пользуешься?
>С пропертями (сахар над геттерами и сеттерами)
Геттеры и сеттеры нужны только когда тебя волнует чёткий момент времени запроса/изменения значения твоего поля. Если тебя это не волнует, они тебе не нужны. Не пиши лишнего без крайней необходимости и не будешь жаловаться на бойлерплейт-код...
>совершенно нормально хотеть и требовать фичи
Хотеть и предлагать - норм, но не требовать же.
>Ты потребитель, а не фанбой на страже веры
А ты думал, что "Godot-культ" - это шутка такая?)))
>ты взрываешься по любой херне
Нейронка в моей голове не умеет писать коротко.
>>утрачивается (много) киллер-фич GDScript
>Каких?
Читай сам:
https://github.com/godotengine/godot-proposals/issues/14652
https://gist.github.com/dalexeev/80ba4c4abda0637701a48095fb1604de
>ты волен делать любую магию
Ну, например, как ты предлагаешь упаковывать свои DLLки внутрь tscn? А GDScript позволяет насрать любым кодом внутрь tscn, с единственным значимым исключением - нельзя объявить class_name (потому что эти внутренние скрипты не видны из ClassDB или типа того, не помню, это какое-то фундаментальное ограничение было). Одно дело - если у тебя компиляция в собственный байт-код, который можно упаковать в PCK/SCN и использовать на любой платформе (как GDScript сейчас), а тут по сути предложение выкинуть "Script" из "GDScript" и сделать "GDC++".
>Надо просто выкинуть variant
Без Variant невозможно (или чрезвычайно трудно) написать многие приложения в принципе... Как ты будешь работать с нетипизированными (по определению поставленной задачи) данными в типизированном языке программирования, если у тебя нет специального типа Variant? Если взять объектно-ориентированное программирование, то класс Object - это что-то наподобие Variant. Но в GDScript типы bool/int/float/string/array/dictionary и т.п. почему-то не кастуются в Object (хотя строки, массивы, векторы, трансформы и т.п. имеют кучу методов и, следовательно, являются объектами с точки зрения языка), и это бесит, поскольку вынуждает юзать Variant или Array[Variant] вместо очевидного Object... От Variant можно отказаться, только если даже bool/int/float будет Object.
>сделать JIT cо спекулятивной оптимизацией
JIT хотели сделать давно, но JIT не даст тебе DLLки как ты требуешь.
>как минимум годот 17 (или годот 9 если китайцы помогут)
И как я должен принимать такую "шутку"? Мы Godot 5.0 можем в своей жизни уже не дождаться (кто успеет раньше - ядерная зима или Godot 5.0?), потому что до него ещё лет пять, а ты тут шутишь про десятки промежуточных мажорных версий, клоун. Godot старается следовать https://semver.org/ и не ломать совместимость лишний раз, а ты ещё недоволен чем-то...
>packed массивов
Толку мало, одно сплошное неудобство - бесят...
>и эта шляпа сразу закинеться на кэш процессора.
Тебя не должен беспокоить кэш процессора, когда у игроков сейчас по 32 мегабайта этого кэша как минимум, а у кого-то уже и больше сотни. А если тебе действительно необходимо втиснуться в кэш процессора, то ты знаешь, что делать: C++ в руки и пересчитывай каждый байт в памяти. Не можешь? Тогда ты и про кэш знать не должен. Понимаешь, в чём дело? Кто знает про оптимизации по кэшу, тот уже имеет опыт C/C++ и пересборки движка из исходников. А кто про это только поверхностно слышал - тот всё равно не сможет написать оптимальный код, даже если у нас будет GDScript -> C++ транспилер и пересборка одной кнопкой.
>>1105751
>когда у тебя все на мелких сервисах
Зачем ты сам себе усложняешь жизнь?
>У тебя на сигналах.
>У меня на сервисах/менеджерах.
Не вижу принципиальной разницы. Что делают твои "менеджеры"? У меня тоже часто есть "менеджеры", которые добавляют, изменяют, удаляют или резервируют объекты определённого типа. Но это не мешает объектам сообщать о своём статусе через сигналы, типа "я умираю, подготовьте мне гроб и яму". Если ты не используешь такие сигналы, то что делаешь ты? Проходишь по всем нодам через for each, заглядывая каждой под дверь и спрашивая "что ты там делаешь"?..
>динамическая типизация требует большего скилла
И что теперь? Много чего требует большего скилла, и поэтому никто в своём уме не будет это использовать, чтобы не пораниться и никому не навредить по своей ошибке. В цирке метатели ножей могут поранить человека, в которого они кидают ножи, но ты же не будешь говорить "фуууу, а почему клоуны не кидают ножи, они что слабаки что ли, пусть тоже кидают, это ведь требует большего скилла", я надеюсь? Или вот для подъёма вверх использовать верёвку сложнее, чем идти по обычной лестнице с перилами, но ты же не будешь говорить "фуууу, а почему в домах есть лестницы с перилами, нужно срочно всё демонтировать и заставить людей подниматься на 20-й этаж по верёвке из окна". Так и типизация в языках используется, чтобы было удобнее и безопаснее. Доводить "безопасность" до шизы Rust-фанбоев, конечно, не надо.
>>1105776
>ценой того что тебе нужно многое держать в голове и нужно быть более внимательным
Забыл добавить "ПРОСТО": "просто держать в голове". Она же у тебя резиновая, видимо.
>А потом, с опытом, ты выбрасываешь снаряжение, оставляешь нужное и идешь налегке
...а потом твой труп снимают вертолётом через несколько недель поисков. Знаем-знаем.
>>1105777
>Быстро прототипириуешь.
Статическая типизация не мешает быстрому прототипированию - скорее, наоборот, помогает, ибо позволяет IDE угадывать и подсказывать нужные тебе методы и поля объектов. Подумай сам: если ты пишешь функцию с Variant аргументом, то IDE вообще без понятия, что ты собираешься в эту функцию загружать, и тебе приходится переключаться на другой файл, напоминать самому себе API своих же или чужих объектов, и потом надеяться, что напечатал их без опечаток. А если ты опечатался - то придётся всю игру перезапускать заново, ведь компилятор не может никак твой код проверить и заранее предупредить. А если ты написал этот код вчера/неделю назад и теперь уже забыл, что ты хотел обрабатывать в этой функции? Без метки типа будет трудно разобраться с тем, что же ты реально делаешь в этой функции, когда у тебя под сотню разных похожих объектов.
Со статическим типизированием ты тратишь условно 2 или 3 секунды на печать типа объекта, который хочешь обработать функцией, и это позволяет IDE подсказать нужный метод или поле без переключения вкладок редактора, и даже намекнуть на то, что код, скорее всего, неправильный и упадёт с ошибкой. А через день/неделю ты легко вспомнишь, что делает твоя функция, только лишь увидев свою метку типа в аргументах функции. Поэтому, только дурак будет говорить, что он "ускоряет прототипирование" экономией 3 секунд на наборе метки типа в аргументах функции, когда самые большие затраты не на набор кода, а на обдумывание, чтение и анализ написанного, которые удлиняются тем больше, чем менее очевидно/явно написан код.
>>1105805
Ты что-то путаешь. В GDScript это делается меткой ":=", пример:
>var a = 10
>var b := 10
>a = "text" # ОК
>b = "text" # ошибка: String присваивается к int
Данный приём наиболее эффективен при создании объектов:
>var button := Button.new()
Будет на 100% идентично (строгая типизация + видно тип невооружённым глазом):
>var button: Button = Button.new()
Поэтому в случае с ООП использовать ":=" предпочтительнее, чем явную метку типа.
Также это можно комбинировать с кастингом для надёжности:
>var control := object as Control
Если object не является потомком Control, то в control будет null.
> Ты что-то путаешь.
Нет, я ничего путаю. Я писал о разных подходах в языках, и очевидно приводил примеры в псевдокоде.
>очевидно приводил примеры в псевдокоде
>примеры того, что уже есть в GDScript
>в треде, где обсуждают GDScript
>порисовать в блендере комнатки и походить по ним
Ты можешь даже прямо в Godot свои комнатки порисовать:
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html
Текстурам можно включить трипланарный маппинг в настройках материала:
https://docs.godotengine.org/en/stable/classes/class_basematerial3d.html#class-basematerial3d-property-uv1-triplanar
Но изучение движка лучше всего начинать с официальных туториалов отсюда:
https://docs.godotengine.org/en/stable/getting_started/introduction/index.html
И дальше туториалы по списку из левого меню "getting started", они очень полезны.
Если хочешь перевод на русский, замени en на ru в ссылках, но он не всегда полный.
>какой годот брать чтобы было попроще?
Бери самый актуальный и стабильный - на сегодняшний день 4.7.2, а позже обновишься до 4.8.
Сборки с метками "dev", "beta", "rc" и "master" предназначены для тех, кто знает, что он делает - в первую очередь это нужно для проверки существующих проектов с будущими нововведениями (или когда не терпится уже начать использовать эти нововведения до релиза stable), поиска багов движка и создания отчётов на github о том, что что-то не работает, чтобы "stable" была реально стабильной (иначе приходится выпускать патч-версии: 4.7.1 и 4.7.2, например). Новичку все эти промежуточные версии только навредят, потому что в них много багов и "экспериментов".
Сборки старше 4.7 (4.6, 4.5...) и тем более сборки 3.x (3.6, 3.7) предназначены для поддержки старых проектов, которые уже вышли в релиз и по какой-то причине не могут обновиться (как правило это зависимость от устаревшего аддона, ограничения старой платформы, слишком глубокая интеграция в код игры устаревших функций старой версии движка и т.п.). Брать их новичку не рекомендуется, если твой компьютер и целевая платформа твоих игр поддерживает актуальную сборку движка. Если ты делаешь чисто для себя или "поиграться", то о сборке не беспокойся и бери просто то, что запускается на твоём компьютере (если компьютер очень старый, возможно, потребуется взять x32 сборку).
Если не хочешь программировать, можешь взять готовый аддон/шаблон для FPS (first person shooter), который можно найти в Asset Library или Asset Store (второе доделали недавно, так что контент может отличаться):
https://godotengine.org/asset-library/asset?filter=first+person
https://store.godotengine.org/search/?query=first+person
Но всё равно придётся разбираться, как всё устроено, и лучше иметь базовое представление, чем вслепую тыкаться. GDScript только поверхностно напоминает Python - на практике он проще и доступнее новичкам.
>А почему для этого нужна обязательно динамическая типизация?
Просто быстрее, ты отключаешь режим умной макаки и умышленно говнокодишь. Типы некуда не деваются, просто ты мыслишь не теми рамками.
Но да, когда у тебя есть выведение типов, а редактор может гарантированно рефакторить все случаи - тебе это не нужно. Но гарантированный рефакторинг возможен только у джава или сишарп господ в нормальных IDE.
>отключаешь режим умной макаки и умышленно говнокодишь
Сколько лишних слов чтобы сказать "я тупой говнокодер"...
>Ты - автономный человек: дышишь, питаешься, занимаешься метаболизмом.
Твоя проблема в том, что ты через аналогию пытаешься понять/объяснить программирование. Все эта аналогия не имеет значения.
Не бывает 100% изолированного модуля, но мы можем сделать его чище.
Даже в хаскеле япуться с монадами, потому что реальность такая какая есть (а не формальный/математический идеальный мир в вакууме)
>>1105814
>Ты издеваешься?
Нужно только принять что единицей модуля у нас сцена, а не каждый скрипт
Тогда все правильно если родитель делает так (инициализирует предков):
var n = $Node
n.setup(self)
А в дочке:
var ctx: Parent
func setup(context: Parent):
....ctx = context
Но если ты начал юзать DI так тоже делать не нужно, хотя допустимо.
>Геттеры и сеттерыя
Если в языке нет пропертей, в промышленной разработке нельзя было делать публичные поля класса, потому что в будущем это ломало API. Это важно когда у вас в команде больше чем 1 человек.
С появлением пропертей стало возможно публичное поле прозрачно заменить на проперти со скрытыми геттерами и сеттерами. Проблема исчезла. привет джависты
>>>утрачивается (много) киллер-фич GDScript
>>Каких?
>Читай сам:
Так там проблема миграции GDScript to GDExtension.
То есть, челики создали такой деревянный GDExtension, что при миграции все пожрут говна. Это правда, но это проблема GDExtension.
На самом деле проблема в том что GDExtension нужно угодить всем языкам. Ты делаешь среднее по больнице API. Но когда у тебя свой язык - ты можешь делать абсолютно любую магию заворачивая её в новые операторы или аннотации (или вообще все что угодно). Они это и делают, это не заслуга динамической природы гдскрипта - это заслуга что он более родной к системе.
>упаковывать свои DLLки внутрь tscn?
А может не надо? Все это "блендеровское" желание держать все ресурсы в себе - только вводить новичков в заблуждение. Есть сущность - пусть лежит в файловой системе рядом. А то срать мета файлами можно, а ресурсы рядом положить нет.
>Без Variant невозможно
>Array[Variant] вместо очевидного Object
Это все проблемы архитектуры. Если начинаешь с типизированного языка, таких проблем не собираешь кроме проблем инвариантности и ковариантности.
Но если ты выкинешь наследование и сделаешь все на трейтых (раст) или через композицию структур (golang) у тебя проблем не будет (наверно, никогда не изучал это глубже).
Вообще, если бы я делал свой годот я бы взял язык похожий на голанг, но без дизайнерских проблем языка.
>>как минимум годот 17 (или годот 9 если китайцы помогут)
>И как я должен принимать такую "шутку"?
Мы ждем идеальный годот и гдскрипт, но здраво понимаем сколько это займет работы, поэтому откладываем на заведомо нереалистичную, утрированную дату и версию.
Я еще никогда шутки не декомпозировал. Спасибо.
>>packed массивов
>Толку мало, одно сплошное неудобство - бесят...
Согласен, Copy On Write портит все удобство и создает трудности на ровном месте. Хотелось бы чтобы packed был просто IList
>Тебя не должен беспокоить кэш процессора, когда у игроков сейчас по 32 мегабайта
А толку, когда у тебя каждое значение это поинтер? Ты кладешь на проц данные, а они все из ссылок на память. И вместо того чтобы посчитать на лету за 10 наносекунд в кэше весь массив, он дергает каждое значение из ОЗУ ценой в 200 наносекунд каждый. Вот и думай.
Если что packed - массивы упакованные по значению. Они всей пачкой лягут на кэш проца (не совсем уверен про строки, я не знаю как строки представлены в годоте, но должен, иначе смысла нет)
>>когда у тебя все на мелких сервисах
>Зачем ты сам себе усложняешь жизнь?
Это тоже что и ваши плагины. Только с другой стороны. Это чем-то напоминает трейты. Ты сервисами добавляешь поведение (ходить, летать, кушать, драться итд), при этом объект все еще сохраняет "объектность" и не становятся анемичный объектом. В 2Д играх (3Д я не делал) очень много общего кода у всех.
>Не вижу принципиальной разницы.
Я использую сигналы только как ивенты. Но я вижу по сорцам и примерам многие через сигналы организуют львиную долю логики. Можно ввести правило - если для сигнала используется только один слушатель - сигнал не нужен. Но каждый делает как хочет. Не хочу за это даже спорить.
> Если ты не используешь такие сигналы, то что делаешь ты? Проходишь по всем нодам через for each, заглядывая каждой под дверь и спрашивая "что ты там делаешь"?..
Нужно помнить вызов сигнала это просто вызов функции. А значит можем вызвать целый менеджер который отвечает за смерть.
//...mycode...
deathManager.notify(self, DeathManager.DeathType.ASS_EXPLOSION)
//...mycode...
Вообще есть несколько способов организации кода (кроме сигналов), через
-Менеджеры
-Почти все на сервисах
-Анимичная модель (ближе к ECS)
-И сама ECS
Причем это все это все похоже на эволюцию. Потому что в бизнесе к анимичной модели пришли еще 20 лет назад.
Но у сигналов в годоте есть исключительная фишка - они создают контракт. А если привязывать через редактор - создают слабую связанность. Нравятся сигналы - юзай, годот способствует этому. Но мне важна отладка и сопровождение кода.
PS Перестань смотреть на программирование через призму аналогий реального мира. Ты из-за этого графоманишь фигню.
>Сколько лишних слов чтобы сказать "я тупой говнокодер"...
Ну, когда ты всю жизнь писал только на уровне говнокода и не видел больше ничего другого - тебе и понижать уровень не нужно, удобно.
>Ты кладешь на проц данные, а они все из ссылок на память
из указателей на память. но кому не пофиг
>Это тоже что и ваши плагины.
Это тоже что и ваши компоненты.
>Все эта аналогия не имеет значения.
Имеет, в контексте геймдева - в этом больше смысла:
https://en.wikipedia.org/wiki/Agent-oriented_programming
>принять что единицей модуля у нас сцена, а не каждый скрипт
У тебя меню. В меню - кнопки. Меню - это сцена. Кнопка - ...?
>var ctx: Parent
>func setup(context: Parent):
>....ctx = context
Ты из кнопки будешь дёргать меню через ctx.do_action()?
Или всё же сделаешь pressed.emit() и _on_button_pressed?
>создали такой деревянный GDExtension
Это уже минимум вторая реализация, первой была GDNative.
>проблема в том что GDExtension нужно угодить всем
Именно так, это одна из киллер-фич всего Godot в целом.
>Но когда у тебя свой язык - ты можешь делать...
Но тогда отваливается киллер-фича Godot.
>Есть сущность - пусть лежит в файловой системе
И будет у тебя что-то наподобие:
>main_menu_button_blinker.gd
>main_menu_logo_rotator.gd
>main_menu_shader_enabler.gd
>main_menu_label_typer.gd
>main_menu_signal_connector.gd
>main_menu_space_expander.gd
>main_menu_particle_swirl.gd
>main_menu_node_shaker.gd
Которые нигде кроме main_menu.tscn нельзя использовать (а переписывать универсально - лень, ибо нужно специально абстрагироваться от меню, а потом этому меню потребуется свой локальный вариант, который учитывает особенности именно этого меню... и зачем было писать универсально?).
>Copy On Write портит все удобство
Портит удобство то, что Godot не даёт всех методов Array на Packed, а конвертация Array<->Packed затруднительна. Когда ты ВНЕЗАПНО получаешь Packed из API Godot, тебе приходится сначала конвертировать его в Array, поработать с ним чего API Array, а потом обратно конвертировать в Packed, чтобы отдать API Godot. Смысл? Может, в каких-то специфичных случаях Packed даёт преимущество в миллион раз по сравнению с обычным Array, но если преимущество, условно, только лишь "наносекунда против 0.5 наносекунд", то нафиг его...
>Ты кладешь на проц данные, а они все из ссылок на память.
Современные процессоры запрашивают все потенциально нужные для будущих операций данные заранее, до того, как они успеют понадобиться. Если в коде развилка - ядро выполняет оба варианта, до выполнения условного выражения. Там какие-то безумные оптимизации специально под ООП, ссылки и развилки, и ты этими оптимизациями полностью пренебрегаешь. Оптимизировать код необходимо только когда эти оптимизация реально возможна, а не просто "ну, я так чувствую, что, вероятно, это будет быстрее, на гипотетическом процессоре из книжек по информатике, который выполняет команды одну за другой и терпеливо дожидается RAM".
Алсо, почитай Хуана: https://godotengine.org/article/why-isnt-godot-ecs-based-game-engine/
>Ты сервисами добавляешь поведение (ходить, летать, кушать, драться итд)
Ты просто ECS пытаешься с нуля переизобрести. Почему не юзаешь готовый фреймворк?
>если для сигнала используется только один слушатель - сигнал не нужен
По такому же принципу придумали "синглтоны" из-за которых теперь страдают все:
>если у объекта (сегодня) нет других экземпляров - конструктор не нужен
Чувствуешь подвох? Сегодня - один, завтра - десять миллионов. Где гарантии?..
>Нужно помнить вызов сигнала это просто вызов функции
Излучение сигнала - это вызов подключённого в данный момент обработчика.
А он может быть не подключён. Или подключён другой. Или сразу несколько...
>deathManager.notify...
А потом окажется, что этому NPC нельзя сейчас умирать, а deathManager его уже убил.
Будешь обмазываться проверками по имени? Или вовремя воскрешать, чтоб не умирал?
Собственно суть сигналов - гибкость (пере)сборки всей системы, будь то один моб, локация, игровая система, менюшка или вся игра. И этим можно даже в реальном времени заниматься, то есть не обязательно тыкать мышкой в инспекторе, хоть это и основа основ.
>Но мне важна отладка и сопровождение кода
Это никак не противоречит сигналам в Godot...
>смотреть на программирование через призму аналогий реального мира
ООП буквально придумали чтобы проецировать реальный мир в компьютеры.
P.S. Перестань проецировать какую-то свою профдеформацию в геймдев...
>Agent-oriented_programming
Ты из-за графомании перепутал автономные агенты и модули. Модули не автономны.
Хочешь близкую аналогию - представь модули как органы человека.
Поджелудочная отделена от печени и выполняют разную работу, но находятся в зависимости от кровотока, нервной системы, других модулей.
Тогда кровоток - это сервис локатор (живи с этим).
>У тебя меню. В меню - кнопки. Меню - это сцена. Кнопка - ...?
Все зависит как задизайнили UI фреймворк и другие требования.
Если кнопка очень сложная и повторяется как в текущем меню, так и еще где-то (тулбаре в каком-то) - очевидно хочется её в сцену.
А если это простое меню, то оверхедить не нужно.
Все по ситуации (и возможности UI, иногда вопреки делаешь как задумали в фреймворке, а не как ты хочешь, в мире до сих пор не пришли к единому UI стандарту).
>Ты из кнопки будешь дёргать меню через
Клик по кнопке - чистый ивент.
Никто не говорит что организация на сигналах плохо. Я говорю его трудно будет сопровождать, когда у тебя на каждый чих логики - это сигнал.
Смотри, в любой метод ты провалишься дебагером, а в loop диспетчера ты попадешь? Перешел ручками раз в сигнал, потом ручками другой. А правильно ты перешел? А был ли между переходами еще логика, точно ничего не упустил? Как получить весь стектрейс (спойлер: никак)?
>>Но когда у тебя свой язык - ты можешь делать...
>Но тогда отваливается киллер-фича Godot.
Ничего не отвалиться, если не натягивать на GDExtension
>Портит удобство то, что Godot не даёт всех методов Array на Packed
Необходимость конвертации нивелирует преимущество, даже делает хуже (это выглядит на уровне безумия, если нет оптимизаций). Я согласен что нужен полноценный API, а не инородные для системы огрызки.
>Алсо, почитай Хуана
Это тема движкосрача. Мне субъективно видно что его цель сделать движок для вката новичков. Отсюда и эти огрызки packed. Или наличие абстрактных классов без интерфейсов - когда работа уже вся сделана.
Просто, вменяемая работа packed и возможность использовать структуры в них, дало бы реально гигантское преимущество для овер-больших массивов (даже без всякого ECS). Нормально когда появляются тулинг для оптимизации. Шарпы тоже не идеальные, но мягкие завозят всякие плюхи если хочется нативно подрочить (в основном не срать в аллокацию, так то шарпы и так нативны).
>А потом окажется, что этому NPC нельзя сейчас умирать,
Менеджер по смертям - это единственный компетентный орган в системе, которые знает нужно ли NPC сейчас умирать или нет. Это центр управления смертями. Но опять же там тупо общий код, сущность оборачивает менеджер
func do_deth():
...//какая-то логика юнита
...Game.deathManager.registry(self) // регистрируем и оповещаем.
...//какая-то логика юнита
>ООП буквально придумали чтобы проецировать реальный мир в компьютеры.
Это невероятно тупая херня из книжек. Чем ООП реально прижилось это отдельная тема.
В реальности твоя машина никак не унаследована от транспорта. Она просто имеет общие свойства.
>>Но мне важна отладка и сопровождение кода
>Это никак не противоречит сигналам в Godot...
Я уже говорил - отладка. На каждое нытье у меня есть обоснованная причина, но вместо вопроса "почему" - ты пытаешься победить меня аналогиями.
>P.S. Перестань проецировать какую-то свою профдеформацию в геймдев...
Не без этого. У меня на годот вообще целая патология "синдрома утенка", но я терплю, справляюсь, лучшего инструмента (для меня) тупо нет.
> машина никак не унаследована от транспорта. Она просто имеет общие свойства.
Звучит как наследование. Не просто общие свойства, а наименьшие общие свойства.
> в мире до сих пор не пришли к единому UI стандарту
Пришли. Ещё во времена delphi потом под разными названиями перетаскивали то в qt то в gtk потом майкрософт перетащила себе в шарп вместе с разрабами delphi и там они запилили финальную версию как это называется: MVVM
Я к тому что транспорт не рожает машину. Человеческая классификация не является наследованием, это просто классификация по свойствам (то есть, даже наоборот, мы обобщаем). То что машина состоит из дверей, двигателя - это больше агрегация (или композиция в случае органов человека). Вот где реальное отражение мира.
Это наследование в рамках классификации. Что-то вроде булевой логики но над множествами. Ты драматизируешь на ровном месте.
>Пришли
Тем временем только у майкрасофта:
Win32 - 1985
MFC - 1992
WinForms - 2002
WPF - 2006
Silverlight - 2007
Xamarin (Forms) - 2014
WinJS - 2012
WinRT (XAML) - 2012
UWP (XAML) - 2015
WinUI - 2018
MAUI - 2020
WinUI 3 - 2021
>Это наследование в рамках классификации. Что-то вроде булевой логики но над множествами. Ты драматизируешь на ровном месте.
Не забывай что я сказал в контексте этого
>ООП буквально придумали чтобы проецировать реальный мир в компьютеры.
Есть целый холивар на тему как ООП создан отражать реальный мир. Но в реальности он ему даже чужд.
В мире чаще встречается агрегация и композиция (можно термин объединить)
> WPF - 2006
Вот здесь изобрели финальную форму и дальше всё было то же самое MWWM только под разными углами.
ООП неплохо описывает самую совершенную модель мира - иначе говоря, наиболее компактную и абстрактную, которую создает наиболее развитый интеллект на Земле - человеческий.
У тебя затык в том, что ты считаешь, что все компоненты плавают независимо как в бульоне - но наследование про соотношение в множествах компонентов. Множество тут математический термин, а не обозначение много.
>Вот здесь изобрели финальную форму и дальше всё было то же самое MWWM только под разными углами.
Мягкие ппц как любят придумывать термины.
Как-будто нужен был срочно свой MVC, но только модный и молодежный (а еще MVP не зашло массам).
И тогда начали высираться те картинки где MVC такой однонаправленный, топорный и неповоротливый. А MVVM модный и молодежный, двунаправленный.
Но кто, блин, запрещал контроллеру возвращать состояние без модели? В фундаментальное тогда архитектурное различие? Это выглядит как подмена понятий.
Реальная проблема MVC была в том что очень часто хотелось насрать логикой во вьюху. И вот тогда появилось что-то типа понятие виджетов
>ООП неплохо описывает самую совершенную модель мира
ООП должно было помогать декомпозировать предметную область. А в реальности, в промышленной разработке, люди через кровь и боль пришли к анемичная модели. То есть, буквально выкинули понятие самого объекта как самостоятельную сущность. Появились Entity которые стали представлять собой объекты без поведения и Service - поведение без состояний (данные которые можно изменить).
Весь абсурд в том, что вся разработка вернулась к структурам (Entity) и функциям(Service), то есть к процедурному программированию.
PS В обучающих материалах можно легко представить машину, собачку или банкомат объектом. Но реале так код никто не пишет.
Интересно ты скриншот обрезал. Воистину зумеры не читают дальше заголовков.
Я хотел показать дату как давно люди естественным способом перешли к анемичной модели.
А так да, автор там ноет что его никто не слушает и вертели его на одном месте (ООП).
Я не знаю что там у шарпов, но анемичная модель плотно легла в основу основ - Java EE и потом уже во спринги и прочее. По другому даже не воспринимают (и это не из-за хорошей жизни)
>>1105870
>представь модули как органы человека
Сердце можно извлечь и заставить гонять кровь отдельно от тела. Можно вставить искусственное сердце, которое тоже само по себе может работать. Функция "качать жидкость из А в Б" никак не меняется от того, находится сердце или его заменитель внутри тела или снаружи тела. Если этому сердцу нужен сигнал снаружи "слышь, сокращайся", то сердцу важен только сам сигнал, а не то, что этот сигнал производит - родная нервная система или искусственный регулятор сердечного ритма. То есть модуль сам по себе живёт (даже после того, как всё остальное тело умерло), и поэтому его возможно заменить. А если бы сердце требовало "вот этот конкретный мозг и никакой другой", мы не могли бы пересадить сердце одного человека в тело другого человека...
Я бы описал разницу между "модулем" и "агентом" в близости взаимосвязей: модули находятся поблизости и двигаются вместе (как нода и все её ноды-потомки), а агенты могут находиться на значительном расстоянии и двигаться независимо (как ноды под разными родителями). Но и в том, и в другом случае подразумевается некоторая степень "автономности", то есть любая нода может обладать своим _process, _input и т.д., действуя по обстоятельствам в окружающей среде.
>очевидно хочется её в сцену
А у тебя Button.new() в Godot - это одна (1) нода, а не сцена. Живи теперь с этим...
>когда у тебя на каждый чих логики - это сигнал
Не доводи до абсурда. В "call down, signal up" сигналы идут только вверх, а не вниз.
>Как получить весь стектрейс (спойлер: никак)?
У меня часто при ошибках Godot вываливает весь маршрут:
>1. _on_thing_event(foo) <-error
>2. event.emit(bar)
>3. whatever()
>4. wtf()
Так что очень легко разобраться, откуда пришла ошибка.
>орган в системе, которые знает нужно ли NPC сейчас умирать или нет
Смотри, я беру ружьё со шприцами и стреляю в NPC сывороткой бессмертия, чтобы мгновенно обезопасить его от взрыва бомбы. Я получил ссылку на NPC с помощью рейкаста, и убедился, что получил именно NPC, а не стену и не коробку. Я бы мог сделать, например, "npc.health = null", чтобы предотвратить возможность уменьшения здоровья у этого NPC (health = RefCounted и просто исчезнет вместе со всеми её сигналами), но вместо этого я должен искать ("сервис-лоцировать", как ты любишь говорить) какой-то "орган в системе", который единолично отвечает за всех NPC во всей вселенной, включая тех, что в данный момент физически не существуют (находятся в другой локации, например, на другой планете), и запросить у него бессмертие для этого NPC? Что за бред?
Ты можешь сказать "это нарушает инкапсуляцию", на что я отвечу - если health написан без "_", то это публичное свойство и в него может ходить кто угодно, в том числе затирать нулём. Проблемы?
При этом избавляемся от глобального сервиса-синглтона и бессмысленных инъекций куда попало.
>Это невероятно тупая херня из книжек.
У тебя какая-то больная мозоль с этим связана? Я не говорю, что ООП - это то, как устроен реальный мир, но ООП удобнее всего для ПРОЕЦИРОВАНИЯ концепций из реального мира в мир виртуальный. Другими словами, если для тебя "машина" - это объект, то так и создавай class Car, у которого тем или иным способом описаны свойства (объём топлива, максимальная скорость и т.п.) и методы (ехать, остановиться, повернуть, заправиться и т.п.). Это УДОБНО. Тебе не нужно выдумывать какой-то абстрактный "ехатель", не нужно хранить объём топлива в гигантском массиве всех топливных бочек во вселенной и искать нужную бочку по порядковому номеру для заправки; ты хранишь всё, что тебе нужно, внутри одного "объекта", который ты видишь в ИРЛ реальной жизни.
Да, на практике ты можешь описывать какие-то объекты, которые не существуют "в реальной реальности", но факт в том, что эти объекты существуют в твоей голове - как некие мысленные сущности. Если ты пишешь книгу, ты описываешь вымышленных персонажей, у которых нет реальных тел и реальных мыслей, но эти персонажи существуют в рамках твоей книги. Так и с программированием - ты можешь создать вымышленный объект, не связанный с реальным миром, но, тем не менее, сама система "описания мира через объекты" оптимальна для моделирования.
...по крайней мере, пока речь идёт о людях с их восприятием реальности и языками. Если взять нейронные сети, то в них могут формироваться "объекты-образы" так, как это происходит в голове человека, не используя при этом никаких языков программирования. Если ты хочешь создать программу, которая останавливается на красный сигнал светофора и едет на зелёный, то ты мог бы создать объект "светофор" и проверять его сигнал, но ты не можешь сделать это так просто, если информация о светофоре поступает с матрицы видеокамеры... Поэтому ты тренируешь нейронную сеть, и нейронная сеть формирует в себе некую репрезентацию "светофора", и ты слушаешь её ответ на вопрос "какой сигнал светофора на этой фотографии". Но это уже немного другая тема для разговора...
Вообще, кому интересно - какая существует альтернатива. Погрызите трейты в rust (трейты существовали и до раста, но там статически типизированный язык без наследования и трейты используются как интерфейсы).
У MVC связи между всеми по кругу - в том числе связь между M и V. MVP и MVVM эту связь убирают, и ViewModel становится менеджером, управляющим M и V.
Люди пришли к антипаттерну. И что в этом хорошего? А софт тогда был качественнее и надежнее - то, что сейчас миллионы вебмакак серят сервисами, не значит, что на них надо ориентироваться. Но человечество в принципе свернуло не туда.
>При этом, добавление print() в этот загрузочный скрипт что-то где-то обновляет и все принты выводятся... но ресурс всё равно испорченный приходит.
Звучит как гонка в многопотоке - ты добавил долго выполняющийся код со строками, и где-то стало успевать прогрузиться чуть больше.
И что они решают? Они все равно компайл тайм, значит компоненты в рантайме не добавишь. И проблему множественного (diamond) наследования они не устраняют - если у тебя два трейта с методом с одинаковым названием, все равно между ними как то различать придется или переименовывать. А в годоте у нас динамическая типизация, без всяких трейтов - has_method() если умеет крякать - значит крякнет.
>Звучит как гонка в многопотоке
Был бы это многопоток, всё было бы проще - зависание или краш редактора.
Повторюсь: @tool-скрипты не всегда обновляются как надо (или никогда... как повезёт). В редакторе скриптов есть отдельная кнопка "Soft Reload Tool Script", но она, как мне кажется, ни на что не влияет как будто. Если ты сохраняешь @tool-скрипт, принадлежащий открытой в редакторе сцене, он может обновиться, а может и не обновиться, но чаще не обновляется, и ты вынужден закрывать и повторного открывать сцену. Если @tool-скрипт привязан к плагину редактора, ты можешь в настройках проекта просто снять галочку с плагина и поставить галочку заново, перезагрузив свой плагин целиком. Но есть особый вид @tool-скриптов, которые используются для загрузки и сохранения кастомных ресурсов (ResourceFormatLoader/ResourceFormatSaver), у которых нет иного способа перезагрузки, кроме как перезагрузить весь Godot целиком. Или я не нашёл. Впрочем, перезагрузить Godot проще, чем искать отдельную галочку...
Итого:
1. Изменил @tool-скрипт.
2. Нажал ctrl+s для обновления.
3. Если не сработало и этот скрипт...
...сцены - закрыл/открыл;
...плагина - выключил/включил;
...Loader/Saver - перезапуск Godot.
>Я бы описал разницу между "модулем" и "агентом"
Сердце не может существовать без симуляции или носителя - это модель. Сердце после извлечение сама стало и пошло, или стало помогать хирургу - это автономный агент.
>А у тебя Button.new() в Godot - это одна (1) нода, а не сцена. Живи теперь с этим...
Чего? Кнопка не может быть сценой? Или что?
>Не доводи до абсурда. В "call down, signal up" сигналы идут только вверх, а не вниз.
В какой вверх? Куда? Почему они не слушают дебаггер и уходят без него? :) можешь не отвечать.
>стектрейс
Пруфов мы не увидим, да? Как и стектрейса до emit
Ладно, дальше графомания, мне лень это разбирать.
Зачем ему зависать или крашиться?
Ситуация 1 - поток-импортер еще не заработал, поток-читатель попросил данные и ему вернули пустой массив длины 0.
Ситуация 2 - поток-импортер начал работать и загрузил часть данных, поток-читатель провел больше времени, пока выводил строки, попросил данные, и ему вернули часть данных, которые импортер успел прочитать - данные неполные.
Легко проверить - попробуй прям долгую задержку вставить в несколько секунд и посмотри, догрузит ли.
>Зачем
Затем.
>попробуй прям долгую задержку
Издеваешься? Проблемы нет больше.
>>1105908
>стало помогать хирургу - это автономный агент
Тогда питомец, ребёнок, старик - не агенты, а модули...
>В какой вверх? Куда?
Вверх по Иггдрасилю...
Объект - это то, что можно выделить из окружающей среды.
Реальный ("реальный") мир состоит из полей - электромагнитного + слабого, гравитационного, хиггса и т.д. все не упомнишь - в "клетках" которого флуктуируют значения (это упрощение, пространство вроде не квантуется на клетки)
Аналогия - игра Жизнь, где просто поле с клеточками, но мы можем выделить такие объекты, как статичный квадрат, мигающий осциллятор и летящий глайдер - как и ирл, можем условно выделить нейтрон и летящий электрон.
Но мы выделяем из него объекты, как в том меме, что человек находит не пятна, а леопарда в траве
Одно из определений интеллекта - это как раз умения находить паттерны - поэтому тест на асикью так работает. Но не только - знаешь, что завтра в час пик пробка - тоже нашел паттерн. (Думаешь, что нашел паттерн, где его нет - или шизик, или гений первооткрыватель)
Так вот, объекты можно определить по ГРАНИЦЕ среды. Например, стеклянный стакан с водой - у него есть паттерн кристаллической решетки стекла, и есть граница с водой, у которой своя структура, и с воздухом. И вот обведенное этой границей мы и называем объектом стакан. Тут свойств вообще можно не касаться.
Компьютерное видение с переменным успехом выделяет объекты на картинке, потому что есть паттерны видимой поверхности И границы между ними.
К чему я клоню? В ООП свойства объектов - может быть не самым главным, а главным может быть граница между объектами и вот уже способы общаться проходя через эти границы, например сообщениями. То есть объект - это таки про инкапсуляцию.
Ну а то, что в программировании появились свои объекты со своей - не вижу тут ничего странного. Это тоже образовало предметную область, в которой стали выделять объекты.
Проблемы нет, только если ты докопался до первопричины и устранил ее.
Представь, что в какой-то момент ты добавишь сохранение, и куда-то запишутся неполные коррапченные данные - а потом ты узнаешь об этом через месяц, и придется переделывать какой-то уровень или модельку.
>У MVC связи между всеми по кругу - в том числе связь между M и V.
Вся идея была в том чтобы отделить модель от вьюхи. Если вьюха исполняет логику - это уже проблема, с ней и была задача бороться.
Собственно, когда пришла идея отделить модель от представления, сразу же потребовался посредник между ними. Так что контроллер это формальный клей (иначе никак, нужна третья сущность). А так как это клей, можешь из него что хочешь делать менеджера/бухгалтера/тракториста, главное чтобы вьюха не срала в модель.
В общем, MVVM это больше маркетинг, чем новая архитектора.
Может быть и маркетинг, но насколько я помню, идея там довольно кардинальная была - контроллер управлял моделью, то есть сухими данными, но элементы интерфейса стали более навороченными - мигать там по всякому анимироваться, добавлять спиннеры - и оказалось, что вьюшке тоже уже нужна какая-то модель именно визуального представления.
>И что они решают?
Они показывают как сделать интерфейсы если у тебя композиция. Причем (насколько я помню и не ошибаюсь) ты можешь реализовать трейт не являясь владельцем структуры это добавляет немного говна в сопровождение кода..
То есть, ты видишь ежика из библиотеки - тебе он нравится, но ты хочешь чтобы он мог работать с системой полета (с функциями которые работают с полетом).
Ты берешь и добавляешь
impl Летательный for Ежик {...}
И все, остается ежика только пнуть и он полетит.
Но, конечно, в рамках барран-чекера там там были подводные камни. Но это проблема раста, а не трейтов
>Люди пришли к антипаттерну.
Антипаттерн по версии очередного теоретика, который набрасывает на вентелятор. Было бы реально антипаттерном выкинули давно.
>>стектрейс
>Пруфы
Вот.
При всеобщем курсе на дермофикацию (enshittification) - вовсе не факт, на что и намекал
>и оказалось, что вьюшке тоже уже нужна какая-то модель именно визуального представления.
Люди хотели срать логикой во вьюхе - мелкомягкие разрешили.
Да, я понимаю о чем ты, где-то в параллельно от мелкомягких вселенной это называли виджетами (и никто не создавал новые понятия).
> ты можешь реализовать трейт не являясь владельцем структуры
Так можно просто отнаследоваться и стать владельцем наследника
Ох блет сколько же мне крови в свое время попили умники, которые запирали наследование через final
>>1105921
>Люди хотели срать
Ппц ты наговнокодил.
Да, я был не прав стектрейс каким-то образом передается сигналу, что делает их не таким говном.
Но ты же наврал слегка. Ты же увидел что await ломает стектрейс (пик4). Но это особенно работы стейт машины в корутинах, это не вина сигналов.
Забавно что дебаггер тоже проходит цепочку вызовов по каждому слушателю.
Если это работает всегда так (нет каких-то исключений, например на другие сцены). То тогда сигналы определенно не говно.
>Так можно просто отнаследоваться и стать владельцем наследника
Это из серии когда ты хочешь пулемет на машину и пишешь такое
Машина extends Пулемет
Код начинает пахнуть
Опять же никто не говорит что это какая-то особенная киллер фича, просто это показывает что можно "по другому", для композиции.
>(нет каких-то исключений, например на другие сцены)
Вроде все работает.
Много вопросов по привязку сигналов через редактор.
1) Во первых у меня один раз годот упал (хз почему, может потому что у меня мышка иногда даблит)
2) Когда создаешь из ноды сцену - коннект горит в редакторе, даже переходит, но связь обрывается. Подобные штуки очень трудно будет уловить, да и сидеть переподключать - такое себе (а я люблю из дерева нод делать сцены).
Как-будто работать с менеджером все равно проще. Ну есть у тебя менеджер по смертям, если ты видишь не выпадает предмет с мертвого юниты - ты знаешь где искать эту логику. А на сигналах что? Сидеть разбирать какой код ловит сигнал смерти и разбирать эту лапшу всю, ну хз.
Да не, ты ж сказал что тебе понравился класс, но ты не можешь его модифицировать
Ну так просто
МояМашина extends Машина
Прям в соответствии с O из принципов SOLID:
>программные сущности … должны быть открыты для расширения, но закрыты для модификации
И оборачивай
drive(param): my_pre(); super(param); my_post()
Которые, поскольку виртуальные перегрузки, будут вызываться в соответствии с L из SOLID:
>Вместо объекта базового типа, можно передать объект его подтипа.
> стектрейс каким-то образом передается сигналу
> сигналы определенно не говно
>наговнокодил
Это ты наговнокодил, читай:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html
>await ломает стектрейс
Просто await - антипаттерн-костыль, как goto/jump. Использование await следует минимизировать.
>>1105930
>один раз годот упал
Это хорошо. Пусть падает - он быстро запускается. Значительно лучше ситуации, когда приложение не закрывается и не выводит ошибок, но и не работает корректно, из-за чего портятся твои данные.
>Когда создаешь из ноды сцену
Ты сначала создаёшь сцену, а потом - соединяешь сигналами внутри и снаружи. Не бывает такого, что насоздавал нод в сцене, накрутил сигналов, а потом: "сделаю-ка вот эти кишки сцены отдельной сценой". Получается, что ты даже не знал, что ты делаешь... Разрабатывай снизу вверх и этих проблем не будет.
>если ты видишь не выпадает предмет с мертвого юниты - ты знаешь где искать эту логику.
Знаю - в коде этого юнита, потому что этот юнит, по нормальной человеческой логике, дропает лут, а не абстрактный глобально-вселенский спавнер лута. В реальности, когда у тебя из кармана ключи падают, "карман" "дропает ключ", а не какой-то "бог ключей". Поменьше мистицизма и разобраться будет проще.
>на сигналах что? Сидеть разбирать какой код ловит
Сигналы ловятся обычно в одном месте: в "предке", создающем и владеющим потомками. Теоретически, возможно подписаться напрямую на любую ноду, но практической пользы от этого мало. Вот, в случае с выпадением лута может быть такая ситуация:
>Потомок: я умираю, есть что-то важное для меня?
>Предок: ок, заспавни вот [этот] лут и умирай.
>Потомок: ок, спавню [этот] лут... (умирает)
Таким образом ты можешь организовать общий пул возможного лута для баланса: умирающий моб берёт предметы из общего пула и отдаёт игроку, и когда в конкретной локации слишком много убийств, новые убийства не возвращают игроку никакого лута, что стимулирует продвижение к следующей локации.
>>1105939
У него какие-то предрассудки от профдеформации - наверное, увидел слово "сигнал" и такой: "а, я это уже пробовал во %вебмакак-фреймворк-нейм%, говно, не понравилось, поэтому здесь даже пробовать не буду".
> стектрейс каким-то образом передается сигналу
Забавно, но школота скорее всего ты (те 15 летние ютуберы-школьники с 5 летнем стажем безыгорности). Во всех других техах инветы не являются прямыми обертками над коллбэками. Это отдельный workflow (или event loop) который не обязан прямо завязываться на текущей стек вызовов и тем более завязываться на работу кадра (_proccess). Но откуда тебе знать, ты же кроме годота больше ничего не нюхал?
Так что радоваться тут нечему. Этот тот случай, когда опять вместо нужной системы событий, дали какой-то поверхностный полу-инструмент, который вообще никак не решает проблему связанности, а только усложняет сопровождение кода.
>из-за чего портятся твои данные.
Это уже бред в стиле наш краш программы лучше чем краш программы у других. Ты в курсе что при краше - не сохраняются данные? Это тоже потеря данных (и возможная порча). В общем, фанбойство какое-то (надеюсь ты шутишь)
>Не бывает такого, что насоздавал нод в сцене, накрутил сигналов, а потом: "сделаю-ка вот эти кишки сцены отдельной сценой".
Разработчик предлагает такую возможность, поэтому вообще не важно что ты там думаешь. Раз он предлагает значит должен гарантировать целостность работы системы.
На самом деле хорошо что привязка через редактор быстро себя скомпрометировала. Это лучше чем потом вручную перепроверять 700 сигналов в проекте (у меня вчера еще и группа отлетела у сцены, тоже мистика).
>Знаю - в коде этого юнита, потому что этот юнит, по нормальной человеческой логике, дропает лут, а не абстрактный глобально-вселенский спавнер
Сразу видно человека, который писал только демки.
Понимаешь дроп, особенно в тайловой карте, может означать поиск свободных ячеек, а это уже не компетенция юнита (нафига ему вообще что-то о тайловом мире знать?).
Это вообще целая система
-Система которая работает со всеми тайлами на карте и определяет ближайщие свободные места (это кстати массив из 62000 тайлов, так что мы тут же упираемся в гдсрипт и variant)
-Система предметов которая хранит предметы определенным образом чтобы по каждому тайлу не проходить каждый раз (дропнулась морковка у зайчика - морковку положить к морковкам и в еду).
-Система которая регистрирует труп как свежую тушу (пометили зайчика как тушу - теперь система поиска еды для хищников знает о новой еде).
-Произвести регистрацию туши в системе порчи (тушка начала портиться).
-Если тушка кровоточила - сообщить системе грязи про дополнительную грязь из крови
То есть, у нас есть небольшая система кровотечения, которая должна отработать и после смерти (недолго).
-система грязи снова опрашивает систему ячеек чтобы разместить уже грязь (тоже нет смысла держать много грязи в одном месте, можно размазать кровь на соседний тайл).
Попробуй эту херню сделать на сигналах, удачи.
> Во всех других техах инветы не являются прямыми обертками над коллбэками. Это отдельный workflow (или event loop) который не обязан прямо завязываться на текущей стек вызовов и тем более завязываться на работу кадра (_proccess).
А как это? А где это в годоте сигналы завязаны на работу кадра? А можно глянуть так сказать, на пруфы? Пока лето не закончилось?
В римке был баг оптимизации, рекомендовали ограничить использование области (рисунка области) "без крыши". То есть, вероятно, юниты в поисках работы, каждый раз инициализировали проверку крыш на карте в этих областях (или вообще везде, раз лагало).
Это как раз проблема когда ты мыслишь агентами. А была бы система, она бы не дергала проверку крыш - если не был сигнал/ивент/флаг связанный с изменениями крыш или комнат или действием игрока.
Это как раз проблема когда ты мыслишь автономными агентами, а проблема системная.
Почему проблема системная? Запустить пепепроверку могут разные оболасти:
-игрок рисует область.
-обрушение или постройка крыши.
-изменение или появление комнаты.
--То есть, мы запускаем проверку крыш не при каждом постройке блока, мы делегируем задачу на систему которая определяет факт создания новой комнаты (а та в свою очередь еще один пласт систем).
Как видишь это уже далеко за область юнита.
Ты так мне в ньюфаче и не ответил. Что правильно.
Ручка.писать(тетрадь)
Тетрадь.писать(ручка)
Не надо демагоги, просто напиши решение одной строчкой.
>А как это? А где это в годоте сигналы завязаны на работу кадра? А можно глянуть так сказать, на пруфы? Пока лето не закончилось?
Поставь брекпоинт перед emit - он пройдет по всем листинерам и после пойдет дальше после emit. Значит flow исполнения не был нарушен - листенеры просто коллбэки.
Ну поставил брекпоинт. А где проход по листенерам?
> Что правильно.
>Ручка.писать(тетрадь)
>Тетрадь.писать(ручка)
Странно, не сохранилось наверное, тебе ответили как правильно по восьмого июля.
По гейдеву лучше что-то вроде МенеджерЗаписей.создать(тетрадь, ручка)
(Демагогией не занимаемся, понимая, что есть некий актор, например игрок, который берет ручку и пишет ей в тетради).
Но если в рамках твоего надуманного ограничения выбирать из двух, то по ISO 15926 правильнее второе, поскольку по стандарту применяют инструмент к более фундаментальному - моделирование завода начинается от крупных построек, агрегатов, к отдельным приборам, и в конце уже к отверткам.
Вместо того чтобы учебники готовить, ты занимаешься фигней. Смотри
Так а стек-то где? На записи просто школьник-калоежка бесконечно фантазирует о своём.
Давай с самого начала, что делает функция принт_стек? Как она связана с сигналами, с работой кадра?
>По гейдеву лучше что-то вроде МенеджерЗаписей.создать(тетрадь, ручка)
Я думал ты сам сообразишь, типа
Человек.писать(тетрадь, ручка)
А не пойдешь искать. Но ладно.
Вопрос вот почему так? Потому что в предметной области ни тетрадка ни ручка сама не пишет. Нужен субъект. Всегда нужен субъект. Так же и в мире программирования постоянно есть менеджеры/системы/сервисы. Так что выкинь агентов (ты вообще достал эту херню из экзотики, там ей решают другие проблемы)
>Так а стек-то где? На записи просто школьник-калоежка бесконечно фантазирует о своём.
Пошли маневры.
Emit возвращает управление обратно - да.
Emit видит весь стек - да
Это буквально тоже самое если вместо сигнала вставить в код
#signal.emi()
_on_1()
_on_2()
Никакой диспетчеризации не происходит.
Так что поссал на тебя и на твои тетрадки. ньюфаня не умеет пользоваться дебаггером
>Никакой диспетчеризации не происходит.
Студент-вебмакака нахватался умных слов у профессора Сычова, который никогда в жизни игр не делал, и теперь с умным видом учит, как нужно использовать сигналы в незнакомом игровом движке...
Хорошо, что уже завтра активность /gd/ пойдёт на спад.
Зато сегодня ты научился пользоваться дебаггером.
Показать где стектрейс спрятали найти? но тетрадки высуши
Постой, ты даже не понял что на видео переходы дебаггера?
>Ты в курсе что при краше - не сохраняются данные?
Описываю РЕАЛЬНЫЕ ситуации, которые могут произойти:
Вариант А, худший:
- какой-то бит флипнулся не так, как должен, и программа этого не заметила;
- программа начала записывать файл, закончила запись и удалила оригинал;
- пользователь не заметил подвоха и продолжил работу как раньше;
- файл - испорчен, и даже в бэкапах сохранился испорченным.
В наихудшем варианте этот баг длится годами => бэкапов считай что не было.
Вариант Б, получше:
- какой-то бит флипнулся, но программа продолжила работу до записи;
- программа успела переименовать старый файл и начать запись в новый;
- во время записи программа заметила подвох с битом и успешно крашнулась;
- после перезапуска пользователем программа восстановила состояние файла.
Да, новые изменения утрачены, но данные сохранены и юзер уже уведомлён.
Вариант В, ещё лучше:
- программа крашнулась сразу после флипа бита, без продолжения работы.
Лучший вариант из всех, т.к. юзер ещё не успел наделать никаких изменений.
Поэтому обычно своевременный краш ПО лучше скрытого подавления ошибок.
Хммм... даже на космическом корабле краш лучше, т.к. там минимум 2 "мозга".
>>1106026
Постой, ты ещё не понял, что тебя разные анонимусы школьником называют?..
Я лично вообще утром-днём сплю, заглянул - а вы тут опять нафлудить успели...
Ты можешь перестать выёбываться и внятно по шагам показать, как воспроизвести подобное явление?
Поэтому удаляют яйца из корзин обычно ПОСЛЕ того как сверят хеши в новых корзинах.
Ну вот блюпринты как раз для меня, для человека с двузначным айсикью
Да-да. Мы подписали две ноды на один сигнал. Мы испускаем сигнал и он вызывается последовательно там же на месте, в том же стеке.
А ты вот так сделай, школота, сильно удивишься.
>Разработчик предлагает такую возможность
Я согласен с тем, что Godot должен как-то явно предупреждать о ситуациях, когда связи сигналов и обработчиков отваливаются из-за действия пользователя. Но если ты уже хорошо разбираешься в том, как устроены сцены в Godot, это не вызовет у тебя удивления. Потому что, когда ты отправляешь какую-то группу нод в независимую сцену, они становятся просто недоступны с точки зрения сцены-родителя. Нужно включить "editable children", чтобы ты получил доступ к этим нодам обратно, но тогда нарушается принцип инкапсуляции сцен. А главное: зачем ты так сделал? Это буквально выстрел в ногу, если ты выбрасываешь кишки созданной сцены, которые ты собственноручно связал сигналами... Это иррационально.
>вручную перепроверять 700 сигналов в проекте
Не вноси так много изменений одновременно. А если что, ты можешь использовать git для контроля того, что именно и когда именно Godot изменяет внутри своих tscn/tres-файлов. Они сделаны простым текстом именно для того, чтобы можно было сравнить версии через систему контроля версий. Тогда ты точно не упустишь изменения, которые Godot мог, гипотетически, внести в сцены, к которым ты давно не прикасался (ты же о них говорил?).
>дроп в тайловой карте может означать поиск свободных ячеек
У тебя буквально только что моб сдох - т.е. клетка под ним освободилась.
>а это уже не компетенция юнита (нафига ему вообще что-то о тайловом мире знать?).
Чё? А как твой юнит двигается по клеткам, если он даже не знает, где может ходить? Ему, очевидно, нужно обладать хотя бы информацией о локальном участке карты - где можно пройти, где нельзя пройти, где стоит союзник, где стоит противник, где лежит лечилка, где есть удобное укрытия для ведения огня из укрытия, где можно спрятаться и т.д. Иначе как он будет принимать решения? А он должен принимать, потому что это его ответственность.
>Система которая работает со всеми тайлами на карте
Если моб может найти путь для движения, то он уже имеет доступ к этой системе.
>дропнулась морковка у зайчика - морковку положить к морковкам
Во-первых, это нужно только игроку и только когда он раскладывает лут по ящикам.
Во-вторых, это происходит только на одной клетке (прямо под твоим дохлым зайцем).
В-третьих, само падение морковки на клетку может триггернуть объединение морковок.
>теперь система поиска еды для хищников знает о новой еде
Херня дизайн. Падальщик сам должен искать еду, а не выбирать из буфета "а не пойти ли мне через всю карту (пять километров) к гниющему зайцу, который успеет уже полностью сгнить и превратиться в скелет, пока я до него доберусь через реки, горы и овраги"... Ты забываешь о том, что делаешь СИМУЛЯЦИЮ ЖИЗНИ, а не "максимально оптимальный калькулятор, который может обработать миллион трупов зайцев за наносекунду".
>Произвести регистрацию туши в системе порчи
Аналогично, полная херня. В играх с гигантским количеством "тикающих" сущностей делают разворот ответственности задом наперёд: каждый тик таймера выбирается набор случайных ячеек карты и производится попытка "тикнуть" то, что в них находится. Таким образом мы снижаем нагрузку на ЦПУ и одновременно добавляем эффект СИМУЛЯЦИИ ЖИЗНИ в нашу СИМУЛЯЦИЮ ЖИЗНИ, поскольку в реальности продукты не портятся с одной скоростью, и растения с грибами и животными не растут с одной скоростью, и даже жидкости не могут математично-равномерно растекаться по реальной поверхности. Ты этого не знал?..
>сообщить системе грязи про дополнительную грязь
Ну это уже натуральная шизофрения "весь мир из атомов и атомы стукаются друг об друга".
>Попробуй эту херню сделать на сигналах, удачи.
Это что, вялый байт на "сделой мне мою игру мечты, суть токова"? Но ты скажешь "не то"...
>>1106002
>инициализировали проверку крыш на карте
Эта проблема решается просто - кэш с флагом dirty, который позволяет не перепроверять то, что уже проверено, а также постановка операции в очередь (queue) в конце кадра, если операция реально затратная. Так что суть не в том, кто это всё запрашивает и как часто, а в том, что система слишком "тупая" - то есть подскакивает делать то, что она уже делала. Представь, что тебя спрашивают - ты приготовил еду? Ты победишь делать еду на каждый такой вопрос? Или запомнишь в своей голове "да, я уже приготовил" и скажешь это всем спрашивающим, пока еда не будет съедена?
Но вообще, ты слишком далеко идущие выводы делаешь из одного "вероятно"...
>Что правильно.
>Ручка.писать(тетрадь)
>Тетрадь.писать(ручка)
Тебе же ответили, что решение зависит от исходной задачи:
- если одна ручка и много тетрадей - первый вариант лучше;
- если одна тетрадь и много ручек - второй вариант лучше;
- если много и того, и другого - лучше объект-посредник;
- если и то, и другое в одном числе - объекты не нужны;
- если условия неизвестны заранее - нужно уточнить;
- если условия изменились - просто рефакторим.
Но зачем расписывать столь очевидные вещи?
>>1106021
Ты другому анону отвечаешь. Научись уже различать по стилю письма.
>Человек.писать(тетрадь, ручка)
Такой подход имеет смысл только если у тебя миллион тетрадок и миллион ручек, и их необходимо все друг с другом подружить или объяснить, почему нельзя подружить. Т.е. данный объект практически бесполезен в 99.99% реальных приложений и игр, поскольку нагружает систему избыточным кодом-клеем тогда, когда он на практике не нужен был.
>Нужен субъект. Всегда нужен субъект
>Так что выкинь агентов (т.е. субъекты)
Опять ты сам себе противоречишь в одном и том же абзаце. Как у тебя так получается?
>CONNECT_DEFERRED
Ты говоришь буквально говоришь отложить, что с тобой?
Еще про call_defered() расскажи.
Двач образовательный
https://docs.godotengine.org/en/4.7/classes/class_object.html#enum-object-connectflags
Как все это поможет пережить 1 сентября, встреча с ОЕТовой и особенно с её чедом??
Начались виляния жопой и переводы стрелок. А что ж такое? Школьничья ам_какаха уже не видит стек? А что такое? Куда привязка к процессу пропала, о которой мы так уверенно кудахтали выше?
> Ты говоришь буквально говоришь отложить, что с тобой?
Я буквально говорю движку делать игоры, и он мне делает. А тебе он какаху за щеку кидает.
> Двач образовательный
Во-во, учи уроки, школотун.
>У тебя буквально только что моб сдох - т.е. клетка под ним освободилась.
Моб может находить на клетке на которой находится предмет или гряз. А вот при смерти он становится предметом, надо положить по радиусу. Смотри пик.
>Падальщик сам должен искать еду,
Пчел у нас 62000 клеток с variant. Мы вынуждены хранить предметы в списках (желательно двухсвязных). Из-за трех морковок на карте бегать 62000 ячеек не нужно.
По поводу гниения. Тик раз в 60 секунд пробегается по списку "гниению" и проставляет новые значения. Мы вообще карту не трогаем.
За вид тушки отвечает сама тушка. Мы вызываем что-то типа
list.take_tickRot(60, Terrain.SWAMP)
В воде гниет два раза быстрее, тушка сама знает как гнить и меняться, мы только даем количество тиков и местность.
>сообщить системе грязи про дополнительную грязь
Нет, грязь тоже не везде и она не пересекается с предметами - предмет может быть на грязном полу. Это тоже отдельный список, только грязь можно даже тупо enum сделать.
>Эта проблема решается просто
Да все кто как-то взаимодействует с крышей должны послать сигнал
GameGlobalEvent.roofInteracted.emit()
Или
AreaManager.roofArea.needRebuildDeffered()
И тогда система меняет флаг и в своем тике полностью пересчитывая, засыпая до следующего раза (там очень редко трогают крышу).
>Но вообще, ты слишком далеко идущие выводы делаешь из одного "вероятно"...
Поэтому римка и лагала. Долбили "крышу" каждый кадр, когда система вообще должна заснуть если с крышей не взаимодействуют. на самом деле я не помню в чем была проблема
Мне уже хочется психануть и написать римку чтобы показать что это все работает и как это удобно сопровождать.
Слишком жирно. Но да, флаги позволяют добиться нужного эффекта.
Слишком жирно было, когда ты начал какахи в код лепить, но не вывез дискуссии. Оказалось, это не годот плохой, а ты неуч.
>Тебе же ответили, что решение зависит от исходной задачи:
Этот вопрос на опыт, даже если человек не понимает предметной области, он может высрать ТетрадьМенеджер.писать(). Третья управляющая сущность всегда лучше, чем перетягивание одеяла между двумя объектами.
>>Нужен субъект. Всегда нужен субъект
>>Так что выкинь агентов (т.е. субъекты)
>Опять ты сам себе противоречишь в одном и том же абзаце. Как у тебя так получается?
У меня агенты это не совсем те агенты, что у тебя в голове.
Агент в игре это юнит в котором помещена вся игра.
А субъект как минимум исполнитель. Это может быть субъект ответственный за открывания дверей (глупо, но почему нет).
> Третья управляющая сущность
Синглтон! Синглтоооон!
>Слишком жирно было, когда ты начал какахи в код лепить, но не вывез дискуссии.
Но какахами стал кидаться не я, а вот этот господин.
>>1105919
Протрезвей.
>а ты неуч.
Умение приманить свои ошибки это зрелость, а вот лбом биться за свое ЧСВ признак психических проблем. Вот и думай.
>>1106056
Это у тебя за деббагер так бомбит?
Мы все сегодня узнали много нового. Ты как пользоваться дебаггером, я что сигналы гибче чем они есть.
>на клетке на которой находится предмет
Это тупое ограничение RimWorld, в других играх такого маразма нет. Elin лучше...
>бегать 62000 ячеек не нужно
Кто-то предлагал бегать? У мобов по определению ограниченное поле зрения.
>Тик раз в 60 секунд пробегается по списку и проставляет новые значения
Согласен, это одна из критических проблем RimWorld - нужно убрать из игры.
>грязь
А если ты захочешь добавить ещё 100500 модификаторов клетки? Добавишь?
>Мне уже хочется психануть
Как будто ты до этого не напсиховал на сотню постов.
>написать римку чтобы показать что это все работает и как это удобно сопровождать
Так пиши, в чём проблема? Ты же уже год или больше хочешь убийцу RimWorld сделать.
>>1106058
>Третья управляющая сущность всегда лучше
Это из-за таких управляторов у нас постоянно начинается срач за области видимости?..
>Агент... А субъект...
Ой, всё. Объект - то, с чем работают (Resource). Субъект/агент - что с кем-то работает (Node).
>Но какахами стал кидаться не я, а вот этот господин.
Если ты не заметил, тут >>1105919 происходит кормление детей. Дети обсираются. Это нормально.
А тут >>1105923 уже началось неприличное метание говном, как будто детей оставили без присмотра.
Но главный ребёнок тут, конечно же, ты. И если не по паспорту, то уж точно - психологически...
>Это тупое ограничение RimWorld
Ну я в контексте сложной игры и говорю
Разные игры разные проблемы.
>А если ты захочешь добавить ещё 100500 модификаторов клетки? Добавишь?
Да это же просто служба поверх TileManager который давно написан.
Я хотел сделать слои земли, чтобы закапывать и откапывать водоемы, устанавливать поверх плодородную землю (легкий терраформинг).
В римке предметы не тонут (быстрее портятся), а вот грязь должна на водной клетке исчезнуть (нужно только сообщить грязьМенеджеру)
>У мобов по определению ограниченное поле зрения.
Зайчик сдохнет на карте 62000клеток со своим полем зрения. Проще дать ему ближайшую травку. Но только не перебором по радиусу, а просто из списка травок найти. Потом пасфаендером чекнуть и зарезервировать травку, отправив зайчика в долгий путь.
Именно поэтому голодные звери в римворде лезут жрать еду поселенцев. Не потому что это скрипт, а потому что зима и мало жрачки, а игрок забыл дверь закрыть.
>>1106062
>Как будто ты до этого не напсиховал на сотню постов.
Это скорее от скуки, я совершенно нейтрален.
Но когда я погружаюсь в реализации римки, появляется желание написать её. А потом вспоминаю какое это говно и все проходит.
>>Агент... А субъект...
>Ой, всё
Ты сам кинул ссылку на AOP и не удосужился копнуть дальше, посмотреть на приложения которые используют такой подход. С этой херней можно дойти до реактивного программирования. А там уже дурка.
Сказал бы просто юнит должен быть rich классом и все.
>Если ты не заметил, тут >>1105919 происходит кормление детей
Там такой треш, что я даже не стал вникать, просто пошел проверил сам.
>Но главный ребёнок тут, конечно же, ты. И если не по паспорту, то уж точно - психологически...
Ну вот, ты довел меня до слез. Тебе не стыдно?
>Ну вот, ты довел меня до слез. Тебе не стыдно?
(погладил по голове и поцеловал в лысеющую макушку) Ну, ну, не плачь...
>>1106066
>в контексте сложной
Сложная игра - это экшон нонтаргет ММО в одном общем мире, а не твоя пошаговая оффлайн дрочилка.
>Да это же просто служба
Вопрос не в том, что это технически (хоть на ассемблере пиши), а в том, что с этим игрокам делать-то?
>грязь должна на водной клетке исчезнуть
...и потом из этой загрязнённой клетки пить нельзя, а если всё-таки выпить - на понос прошибёт? Так?
>Зайчик сдохнет со своим полем зрения
З И С _ И З _ Д И К А Я _ П Р И Р О Д А ! ! ! (пинком отправляю зайчика в полёт на зелёную лужайку)
>зарезервировать травку, отправив зайчика
Какой хороший сервис, обслуживание на 5 из 5, комната со свежей травой и менеджерша красивая...
>появляется желание написать её. А потом вспоминаю какое это говно
Просто нужно было с самого начала порномоды накатить и делать клон не ваниллы, а порномодов.
Возвращаемся к тому, что последние 150 постов не касаются разработки игр, а просто байтодрочь...
>Сложная игра - это экшон нонтаргет ММО в одном общем мире, а не твоя пошаговая оффлайн дрочилка.
Попробуй сделать, офигеешь. Там 90% логики даже не будут дергать API годота, настолько большая глубина механик.
>Вопрос не в том, что это технически (хоть на ассемблере пиши), а в том, что с этим игрокам делать-то?
Игрокам играть. Меня волнует только чтобы сопровождение кода было легким. Чтобы добавление фичи не превращалось в геморрой.
Это достигается за счет модульности и контрактов. Но по хорошему такую игру лучше делать сразу на шарпах. Вот эти все "менджеры" которые бегают по спискам нужны сразу LinkedList, а для двухмерного массива на 62000 ячеек вообще не хочется чтобы там были variant. Но это если ты прям на игру нацелился.
>...и потом из этой загрязнённой клетки пить нельзя, а если всё-таки выпить - на понос прошибёт? Так?
Ты уже волен делать что хочешь. Я много раз говорил - симуляции делать не менее интереснее чем играть в них. Пускай гибнет рыба - меньше разнообразие еды - меньше показатель стабильности в поселение, падает продуктивность - это уже задача для игрока - как её решать (причем не заскриптованная проблема)
В римке есть отравления едой - пешка не только плохо работает/двигается - еще заблевывает кругом.
> (пинком отправляю зайчика в полёт на зелёную лужайку)
Очень забавно когда на старте все начинают жрать твою еду. Это чувствуется когда стартуешь одним колонистом и еще не построил стен. Приготовленная еда имеет больше сытности (и там видимо выбор как по сытности так и по дальности) - многие кто был поблизости начинают тебя объедать.
Это классная незаскриптованная симуляция. Какая-нибудь кучка ворон начинает дико подбешивать (а потом, закономерно, ешь их ты).
>Просто нужно было с самого начала порномоды накатить и делать клон не ваниллы, а порномодов.
Ты кстати играл в LonaRPG? Недостаток таких игр, что их не могут стримить, но судя по описаниям там такой звездец, как раз как в твоей башке.
>Ты кстати играл в LonaRPG?
Не играл, но это, ВНЕЗАПНО, типичная JRPG с порнушкой, а не RimWorld с порнушкой. Порно-клон римворлда существует, я не играл и не запомнил название, но там прям чётко написано было "симулятор колонии с порнухой", то есть твои колонисты могут заниматься сексом и всякими извращениями друг с другом, независимо от игрока. В этом и суть таких игр. The Sims многие играют ради того, чтобы мутить отношения, но без нормального секса это всё как игра в бесполые куклы. RimWorld подарил множеству нормисов возможность играть в куклы с сексом, поэтому и взлетел в популярности. Всё остальное суета.
Если беспокоишься по поводу стримов - очевидно, нужно идти путём RimWorld: ванилла + мод от "третьих лиц". Сам я, кстати, в этот RJW не играл, потому что меня выбесила ванилла и я удалил RimWorld, толком не поиграв.
А выбесило меня то, что игра построена вокруг микроменеджмента кучки дебилов, которые сами выживать не способны, вещи с пола не подбирают, постоянно от чего-то страдают и дохнут. Это фан? Это нифига не фан. Если и делать такую игру, то нужно либо тупых, но выносливых терминаторов, которые могут ломать медведям лица с 1 хп и выживать, либо сверхразумов, которые откисают с одного удара мизинцем об тумбочку, но зато умеют делать все задачи вовремя и не валяют дурака, когда у них всё разбросано по полу, горит и затапливается одновременно. Из-за того, что ИИ для NPC делать сложно, думаю, лучше всего пойти путём выносливых терминаторов и положить болт на все реалистичные уязвимости.
>Это классная незаскриптованная симуляция
Ты же сам написал, почему эта симуляция заскриптована:
>Приготовленная еда имеет больше сытности (и там видимо выбор...
Ты готовишь еду - она становится в приоритете у животных - ты вынужден строить стены и двери. Классическая схема скрытного принуждения игрока к определённым геймплейным действиям. А вот, для сравнения, в Elin нет стимула к строительству стен и домов - и, несмотря на то, что строительство там куда более продвинутое, чем в RimWorld, игрок может остаться бомжевать и складывать на улице весь свой шмот просто потому, что игра никак не пытается простимулировать строительство домиков.
>Попробуй сделать, офигеешь
>симуляции делать не менее интереснее
Но мне неинтересно начинать такую игру... Там в самом начале ничего не происходит - скука смертная...
> то есть твои колонисты могут заниматься сексом
Они там это делают в базовом. А с ДЛС делают детей, роды, воспитание, школа/парты. Есть импланты усиления любви (плюс еще бафы).
>Если беспокоишься по поводу стримов - очевидно, нужно идти путём RimWorld: ванилла + мод
Там в ванилн очень много криминала и без модов. Причем криминал не завуалирован и настолько серьезный что можно сразу отлететь. Тут больше вопросов почему игру еще не отменили и почему она существует в стиме.
>А выбесило меня то, что игра построена вокруг микроменеджмента кучки дебилов, которые сами выживать не способны
На самом деле если в рамках идей римки сделать фулл автоматизацию (или хотя бы на уровне дварф фортрес) - тебе (как игроку) в игре делать будет нечего - прям буквально. Там некоторый микроменджмент придуман оставлен специально. Игра играется на 4х скорости и это проблема геймдизайна. Даже в играх парадоксов ты не часто на 4 переключаешься - то есть тебе есть там чем заняться. А вот римку без фулл скорости неиграбельно - ты играешь в "ждуна" и строителя.
Я хотел разнообразить вылазками, в итоге понял что лучше делать симулятор группы наемников.
>Ты же сам написал, почему эта симуляция заскриптована:
Заскриптованно (как говорят геймеры), если у бы ворон была явная задача (task) приходить и воровать еду у поселенцев. А так это обстоятельства симуляции (хотя почему не побесить игрока случайными скриптами, там точно такие есть - травма мозга уже локальный мем).
>Классическая схема скрытного принуждения игрока к определённым геймплейным действиям.
Да не, это проблема первого урожая (3-4 дня). Римворлд еще называют "рисворлд". Ты можешь одним поселенцем всю фауну кормить. Но вообще игра должна подкидывать трудности.
>Elin
Почему ты еще не сделал свой клон?
>Почему ты еще не сделал свой клон?
А смысл? В игру типа Elin интересно играть только когда кто-то сделал, а ты играешь и смеёшься с приколов автора. Самому делать такую игру - это как смеяться над своими собственными шутками в полном одиночестве. То же самое касается и этого RimWorld... Ну, посмеёшься пару раз с мебели из шкур племени каннибалов... А дальше что? Скука...
>То же самое касается и этого RimWorld
Там есть иммерсивнные моменты. Там какой-то чел годами строил свою идеальную колонию стартуя вампиром девочкой-подростком.
Зачастую там люди играют в какой-то свой римволрд. Я когда разбирался в римке, понял что мне нужен вообще не римворлд (моя иммерсивность от игры в другом и игра сразу схлопнулась до кактуса - чем она и является).
А вот РПГ как-будто резиновая штука. Сделать ставку на реиграбельности, а не сюжетах и у тебя бесконечное поле для творчества. Сюжеты пусть в книгах ищут.
Рогалик больше про одноразовость и забеги
Хз, по мне контакт с продавцом, который с течением времени по "дружбе" дает скидку - куда иммерсивнее чем послушать его офигенную историю в начале.
Как делают кино/сериалах - сначала привязывают к персонажу, а уже потом тебе интересно о нем что-то узнать.
Мол
- О-о да я знаю этого парня, он торгует в Ривервуде
- Что? Он раньше работал в стрипклубе?
>Рогалик больше про одноразовость и забеги
А я думал это когда при смерти персонажа выносишь что-то ещё с собой, кроме горящей жопы, например лут или навыки.
Это более позднее добавление, скорее всего попавшее из инкрементальных кликеров с их "мета прокачкой".
В классических у тебя действительно прокачиваются навыки, только свои, игрока, поэтому ты с каждым разом дальше забегаешь.
>иммерсивнные моменты
Путаешь фан с иммерсивностью.
>РПГ как-будто резиновая штука
РПГ - "как реальная жизнь, но с бросками кубиков" - естественно, что что угодно можно впихнуть в РПГ и фактически любой жанр при усложнении механик стремится к чему-то типа РПГ (реальной жизни).
>>1106093
Наоборот, рогалик - это тип РПГ. Сюжет в РПГ не обязательный элемент, просто большинство ЦА не способны развлекать сами себя, вот им и делают рельсовый сюжет для затягивания в мир игры.
>>1106099
>Рогалик... одноразовость
Наоборот. Рогалик отличается от всех остальных классических разновидностей РПГ процедурной генерацией, добавляющей возможность много раз переигрывать в одну и ту же игру. При этом, если присутствует система сохранения, игровая сессия теоретически ограничена лишь смертью героя... В некоторые ASCII рогалики играют месяцами без перезапуска с нуля, ибо научились выживать.
>>1106100
>при смерти персонажа выносишь что-то с собой
Это относится к rogue-lite - рогалик на минималках.
>>1106101
>попавшее из инкрементальных кликеров
Lolwut? Просто убрали пермасмерть и всё.
Сама суть это отыгрыш роли
Будь то курьер в своем городе
Средневековый наемник
Девочка волшебница
Или егерь отшельник в лесу.
Тут центр внимание на персонаже. Его развитие и приключение. Все остальное декорации для этого персонажа (в том числе и диалоги).
Даже если это группа персонажей - в них должен быть ГГ. Иначе это не РПГ (а симулятор наемников и там другая иммерсивность).
К чему этот высер после школьной линейки? Да к тому - не нужно мыслить шаблонно. Когда говоришь РПГ кто-то либо представляет средневековую шляпу с заданиями из диалогов. А кто-то вообще JRPG. Но в реале РПГ это мега широкая штука, где в неделимой основой, базой баз - является иммерсивность от роли.
Может ли рогалик быть РПГ? НЕТ! В основе рогалика идет - вызов, соревновательный момент - это другие психологические трегеры, там уже ролеплей является второстепенным и прибивается геймдизайнером просто по привычной узнаваемой схеме, но ты не отыгрываешь роль.
Живите с этим.
>Путаешь фан с иммерсивностью.
Да это разное.
Но делать игру чтобы там был только фан - это потратить полгода-год разработки чтобы человек час потыкался и забил.
Это как те моды скайрима, где есть машины, автоматы, паровозики вместо драконов. Буквально 10 секунд ролика чтобы улыбнуло и ты дальше проскролил. Офигенная инвестиция времени для мододела.
В рогалике ты отыгрываешь роль приключенца, что отправился исследовать подземелье с монстрами.
Шах и мат, школотун.
Смотри, давай введем правило - что жанр игры определяет его самый сильный и базовый психологический триггер - все остальное это натягивание привычного на типичное.
РПГ - ролеплей выходит на первое место.
Рогалик - вызов и соревновательный момент. Соулсятина из мира бедных инди игр.
Человек, мотивацией которого был вызов - испытает фрустрацию если ты в середине игры завалишь его диалогами.
Можно что угодно натянуть на что угодно. Но Рогалик не станет РПГ в основе, ты накормишь игрока фрустрацией.
Таже обратная сторона, когда в РПГ суют рогалик и потом начинается вой - какого хрена я прохожу данж 30 раз или дайте мне сохранение перед данжем итд.
Раунд 🎤
>Человек, мотивацией которого был вызов - испытает фрустрацию если ты в середине игры завалишь его диалогами.
Заваливание диалогами - это тоже вызов!
>Заваливание диалогами - это тоже вызов!
Геймдизайнер геншина - залогинься.
Что тут у нас? Пляжный римворлд в факторио?
Почему тайлы дрыгаются?
>Что тут у нас?
Трава растёт, разрушая камни. TileMapLayer лагает.
>Почему тайлы дрыгаются?
Как заметил? Не знаю, как в этом случае это можно исправить. Тайлы изначально были 16x16, и когда я нарисовал им текстуру вместо сплошной заливки, получилась сильная рябь на экране, когда камера отдаляется и двигается. Увеличение до 64x64 не дало ничего, кроме необходимости отдалять камеру ещё дальше... В настройках проекта есть галочка "snap 2D vertices to pixels", она помогает избавиться от ряби на экране, но, видимо, из-за неё получается "дрыганье".
Пофиг, что-то пропало желание этим заниматься.
>>Почему тайлы дрыгаются?
>Как заметил?
Я не про отрисовку. Они то появляются то исчезают, я не понимаю что это.
>TileMapLayer лагает.
Он у тебя один на всю карту? Не думал сделать чанки из серии TileMapLayer?
Зачем? Это не даст никакого прироста, там веутри рендер уже оптимизирован квадтри.
У него тормозит, скорее всего, присвоение тайлов через гдскрипт по одиночке, там надо уже с++ подтягивать, работать мо своими массмвами и потом батчем присваивать, а не читать один, выполнять логику, присваивать один.
>Они то появляются то исчезают, я не понимаю
Охохо, это ты ещё промежуточной версии не видел - скоратил логику изменений для того, чтобы видео получилось понятнее. На видео участки голой земли (коричневые) зарастают луговой травой с цветами, а луговая трава зарастает более густой травой. Ещё у скалистых тайлов есть шанс рассыпаться в почву посредством корней растений с ближайших клеток. Простейшая, базовая симуляция жизни на клетках, аналогичная той, что есть, например, в Terraria. Что, RimWorld разве не симулирует рост растительности?
>Не думал сделать чанки из серии TileMapLayer?
Это будет иметь смысл только если ограничить их обновления видимостью камеры. Мне кажется, куда бОльшего можно достичь, если сделать отдельные "уменьшенные" карты, которые имеют меньшую "детализацию" за счёт объединения тайлов. Вот, для примера, миникарта в углу - это текстура из 100x100 пикселей, она сэмплит данные с шагом в 10 клеток и отображается намного быстрее, чем миллион тайлов, однако, информации в ней более чем достаточно.
>>1106383
TileMapLayer внутри Godot уже батчится, RTFM:
>For performance reasons, all TileMap updates are batched at the end of a frame.
Т.е. сколько бы ты set_cell() не теребил, обновление происходит только в конце текущего кадра. Но это обновление может быть дорогим, если ты обновил практически каждый тайл со всей своей карты.
>работать со своими массивами
Я так и делаю - тайлмап только для отображения. На миникарте используется тот же массив без доступа к TileMapLayer, потому что это просто пиксели.
От C++ на данном этапе смысла нет. Карта осознанно увеличена до миллиона тайлов и их обновления были ускорены до упора в пределах 2-4 мс на кадр, т.е. все наблюдаемые просадки до 20 мс на кадр из-за самой TileMapLayer, которая не вытягивает столько тайлов одновременно в одной Camera2D (GPU скачет с 1% до примерно 20% если отодвинуть камеру подальше).
Короче говоря, чтобы избавиться от просадок, тут необходимо заменять одну TileMapLayer на другую, с меньшим количеством тайлов, прям как в Terraria - отдаление камеры заменяет детальную графику на приблизительную мини-карту, где 1 пиксель - это объединение набора тайлов (или шаг через тайлы). Называйте это "2D Level of Detail" (LOD), например.
Но всё это не имеет значения, если нет геймплея.
Изначально были мысли сделать что-то типа:
https://steamdb.info/app/1206560/screenshots/
Но я в очередной раз осознал, что меня к такому совершенно не тянет. Пиксельные игры обречены оставаться не более чем пиксельными играми...
>потом батчем присваивать
Коррекшн - в 4-ке нет такого метода. В 3-ке можно было передать массив tile_data вида [ координата, tile_id, флаги, ... ]
>>1106397
>От C++ на данном этапе смысла нет
Каждая операция set_cell в теории будет быстрее, умноженная на твои миллионы клеток
>Каждая операция в теории будет быстрее
Болид формулы-1 быстрее трактора, но поле он тебе вспахать не сможет, потому что оптимизирован для гоночного трека с идеальной поверхностью, и даже классический российский асфальт в городе будет существенно снижать его скорость (если не считать скорость вылета с дороги в кусты из-за колдобины).
Улавливаешь?
>все наблюдаемые просадки до 20 мс на кадр из-за самой TileMapLayer, которая не вытягивает столько тайлов одновременно в одной Camera2D (GPU скачет с 1% до примерно 20% если отодвинуть камеру подальше).
Хз, почему ты решил, что просадки из-за рендера тайлмапы, а не из-за рассчетов логики скриптом.
>на котенке с дверцей
Это какой-то мем? Впервые слышу.
>>1106403
>из-за рендера тайлмапы, а не из-за рассчетов
Рассчёты стабильны и не зависят от Camera2D.
От Camera2D зависит только рендер графики.
Какие ещё аргументы нужны?
Ну да, стабильно медленные, те же рассчеты будут стабильно быстрее на c++, что тебя удивляет?
Возьми просто свой тайлмап продублируй с уровнем, но без логики вообще, даже без пустых функций которые только return делают.
Как же я поел говна сегодня с этими packed массивами.
Думал если сделаю плоский массив я получу прирост в цикле. Ага, заверните.
Самое обидное что я написал быстро и почти без ошибок - но мля сел зачем-то покрывать тестами! Два-три часа писал тесты, ловил мелкую багу. Пошел тестить производительность, а мне по губам.
В общем, пока они не завезут сахар для структур, эти пакед массивы бесполезны. Даже адаптируя просто под айдишники (используя Vector4 как подобие кортежа) ты сосешь болт.
>пик4
Это производительность с включенными проверками (выход за границы, проверка максимального целого итд)
То есть, GDScript настолько сильно сжирает на банальном коде, что вообще не имеет смысл делать обертку над packed массивами.
Это фиаско братан! я ожидал что плоский массив не совсем удобен для перебора, но кто знал?
Так а если не упаковывать каждый раз в Vector2i, а просто передаввать x, y и считать x + y * WIDTH?
Да там "плоский" массив.
Блин, ты чем читаешь? Я знаю, что там плоский массив, я тебе говорю что у тебя есть операция боксинга и анбоксинга чисел в vectori, а тут я вовсе не уверен что гдскрипт такое умеет оптимизировать, там же не компилятор. Да и умножать скорее стоит на константу, емнип packed массивы то заточены на константный размер (что, понятно, означает что карта будет фиксированного размера - но не все равно ли? В старых играх просто были разные размеры типа 256x256, 512x512)
Вот теперь смотри что происходит когда я отключаю проверки аргументов.
Пик2 - до
Пик3 - после
Насколько банальные if...else влияют на код, насколько GDScript замедляет списко-дробилки. Безумие!
Завтра свежей головой еще чекну, если кому интересно сорцы кину.
Да я знаю, там копейки (уже гонял). Там еще из накладных int -> float -> int
Сам по себе гдскрипт так тормозит - любые операции добавляют солидную "массу".
Завтра попробую еще поковырять и как-то уровнять даже
А вот тут надо еще нюанс проверить. Не помню, нет ли такого, что комментарии все еще парсятся каждый раз, что может тоже занимать время. Тестишь то ты в дебаге, а не в экспорте релиз билда, судя по всему, где такая оптимизация по откидыванию комментариев и пустых строк, вроде бы, есть.
Завтра пробегусь и скину проектом - кому интересно реабилитируете как хотите (может я не вижу проблему).
А пока я в ахуе.
Когда уже будут нормальные игры в этом ИТТ треде, а не тесты скорости?
> оптимизирует непонятно что
Всем понятно, что ты не понял?
>Когда уже будут нормальные игры в этом ИТТ
Тред про движок а не про игры. Ты с субшотой попутал.
>Не помню, нет ли такого, что комментарии все еще парсятся каждый раз, что может тоже занимать время.
Я закоментил, как-будто текст не влияет.
Но может правда есть большая разница между релизом и дебагом у гдскрипта (да полюбому что-то есть). Надо будет разобраться и попробовать Кто вообще собирает в релиз и кто вообще знает что-то про релиз, дикость какая 🙂
> Кто вообще собирает в релиз и кто вообще знает что-то про релиз
Участники ТВГ
>что вообще не имеет смысл делать обертку над packed массивами
Пакед даёт выигрыш по памяти, т.к. хранит условной байтовый массив, обычный массив хранит список классов Variant, но цифры у тебя слишом сильно разнятся, какие-то косяки в коде скорее, типа вызов сеттера ненужный может, и если не знаешь, почитай о такой замечательной штуке, как функция assert
В доках сказано еще и про фрагментацию памяти. Может быть, у него эффекты появляются из-за того, что массив огромный, кэш там шатает и так далее.
Кстати, тогда идея - делать множество packedarray, например по одной на строку карты.
>Но может правда есть большая разница между релизом и дебагом у гдскрипта (да полюбому что-то есть).
В общем, стало интересно, я ничего не настраивал, дефолтно собрал как есть (и на всякий случай купил слот в стиме).
Действительно лучше, но все равно печалька.
>у него эффекты появляются из-за того, что массив огромный
ну ты же заранее можешь (должен) выделить нужное количество памяти для обеих случаев, ещё и желательно степень двойки ещё и желательно выровненую на 8, хотя из GDS это никак не проконтроллировать.
>Кстати, тогда идея - делать множество packedarray, например по одной на строку карты.
Читай ещё про Array of Structs (AoS) / Struct of Arrays (SoA)
Проблема только в том, что это процессорные оптимизации, утилизирующие кэш современных CPU, а что там делается со стороны C++ при создании массивов и как память выделяется, надо смотреть, вероятно нихуя это не даст в GDS.
>там веутри рендер уже оптимизирован квадтри
Сильно сомневаюсь. Может только в физическом движке
Сам класс (еще даже поиск не сделал)
https://pastebin.com/V3UE0Rst
Тесты (исполнитель, где-нибудь запустите)
https://pastebin.com/d52Jssmj
Я скорее всего где-то обсрался, налажал как последний школьник.
Или годод где-то что-то оптимизирует неплохо и гдсрипт прям вообще не котируется чтобы какие-то обертки делать.
Так что гоняйте и надсмехайтесь, мои полномочия с packed все. после запоя уйду в шарпы!
Хм. Мне казалось, что где-то читал, что там была оптимизация, но сейчас найти не могу. Может, я так думал, потому что есть параметр quadrant_size. Но видел, кто-то писал gdextension, так что может и правда там нет куллинга.
>RimWorld разве не симулирует рост растительности?
Там на земле вообще шейдер (текстура размазана по тайлам), растительность растет медленно и она менее контрастная (кроме ключевой растительности типа посевов или вот дерево души на пикче).
>>1106397
>Вот, для примера, миникарта в углу - это текстура из 100x100 пикселей, она сэмплит данные с шагом в 10 клеток и отображается намного быстрее, чем миллион тайлов, однако, информации в ней более чем достаточно.
Скинь демку. Вообще не понимаю как делать миникарты.
>Я скорее всего где-то обсрался, налажал как последний школьник.
Ну да, ты хранишь int'ы в PackedVector4Array теряя на конвертациях как минимум....
> Вообще не понимаю как делать миникарты.
Я в 3д просто рендерил второй раз мир камерой в текстуру и выводил во вьюпорт гуи.
Дальше уже нюансы. Можно поставить visibility layer камере и объектам так, что главная камера рисует одно, а миникартовая другое, например белый треугольничек.
Надо только пошаманить, если хочется делать стрелочки на объекты, которые за пределом видимости. Ну тогда или в шейдере корректировать координаты, или дублирующий объект создать у которого координаты обрезать.
В принципе окружение можно не рендерить, а заскриншотить или нарисовать карту от руки. Или отрендерить клетки тайлмапы в пиксели текстуры (хотя, может, можно и просто нарисовать тайлмап с тайлсетом в 1 пиксель, надо потестить скорость).
Можно сделать какие то вращения камеры, типа как в навигаторе следование. Ну и другие свистоперделки добаввлять, вроде анимированных линий маршрутов.
Полистал исходники, и вроде бы чанкинг тайлмапы встроенный все же есть, причем отдельно на рендер и на физику. Но он не такой, как ожидаешь, что рисуется регион от и до - а там строятся списки изменившихся клеток. И по идее все это загоняется вв canvasitems которые автомтически куллятся камерой. Но надо тестить, может быть свой чанкинг окажется быстрее. Я вообще не фанат постоянного перестраивания списков там, где можно обойтись парой проверок x < и x >
>Ну да, ты хранишь int'ы в PackedVector4Array теряя на конвертациях как минимум....
Как видишь это ничего не стоит (я даже перестарался). Это на уровне погрешности измерения. Тоже и с Vector2i(x,y). Все вызовы апи движка невероятно быстрые в сравнение с гдскриптом.
Если ты не понял то там PackedVector4Array выступает в роли структуры - кортежа с айдишниками. В теории эта херня должна быть невероятно быстрая (это фактически сишные массивы). Но gdsript превращает эту обёртку в каткус.
Это не говорит что прям гдскрипт медленный (особенно с АПИ), но про серьезные кастомные алгоритмы можно забыть (массив с вариантами и классам работает на порядок(!) быстрее. Даже без проверок ассоциативные массивы чуть медленней).
Так что если нужен римволд или симуляции, то неплохо было бы сравнить годот с версией шарпов.
Больше не выжал. На последнем скрине релиз дебилд, короче не еби себе голову и пользуй Array
Стоп, я >>1106453 тебя обманул немного, я там навставлял доп проверок себе, чтобы с индексами не просрать, вот числа с функциями один к одному просто с заменой класса
Там больше прирост когда выкидываешь проверки.
Там был замысел пройтись по двухмерному массиву и получить картэж из:
Vector4[0] - пустая не пустая клекта 1/0
Vector4[1] - id в списке предметов
Vector4[2] - id в списке грязи
Vector4[3] - резерв
Без кортежа это бессмысленно.
>Там был замысел пройтись по двухмерному массиву и получить картэж
Как видишь у меня в параметрах есть containerIndex
Чтобы собрать и вернуть список тебе надо будет еще 3 раза отдолбить getId
Ты юнит тесты делал? Толку от замеров если они там не валидны.
Можно хоть всю игру запихнуть в одномерный список, все равно массив с variant победит.
Зачем мне юнит тесты, там твой кортеж есть или что?! Если совсем тяжело....
Я провёл более глубокий тест и пришёл к следующему:
1. Время кадра доходит до 20 мс строго из-за рендера даже статичной карты.
2. Время обновления TileMapLayer зависит от числа затронутых квадрантов.
3. В прошлом видео обновление TileMapLayer занимало стабильно 10 мс.
4. Вся моя "логика" занимает около 1.5~2 мс даже без обновлений.
5. Оптимизация: трогать клетки в меньшем числе квадрантов.
6. Квадранты (которые для рендеринга):
- слишком большие (>16) - дольше обновляются;
- слишком маленькие (<16) - дольше отрисовываются.
>>1106439
Твоя проблема - в вызовах функций. Если нет вызовов - Packed быстрее.
Но всё равно, это всё экономия на спичках, и лучше делать игру, а не это.
>>1106446
>Вообще не понимаю как делать миникарты.
Я её по-быстрому накидал, вряд ли это подойдёт твоей игре, но вот.
Можно всю карту нарисовать в _draw(), но решил пикселями в этот раз.
>там твой кортеж есть или что?!
Я не успел написать работу с картежами меня тесты порадовали. Лучше бы я раньше пошел проверять.
А теперь простая математика. Смотри мы тремся на карте 250х250 это уже 62,5К - это уже плохо для списка. А теперь посчитай что будет если умножить на 4. Ну стало вроде побольше, да?
sqrt(250 250 4)
Но неожиданно это размерность карты 500х500.
Теперь у нас карта 250 по цене 500. Да и вообще главное мы лишаем себя сделать больше 250х250 (например 350х350 еще комфортно).
Думаешь там Vector4 просто от балды? Очевидно что я хотел какую-то структуру получить, а не просто итерировать с оффсетом (меня и так размер size^2 раздражал, но это хотя бы близко к Array[x][y]). Алгоритм должен был выжить что-то полезное из packed (который ожидался очень эффективным)
Главный вывод, в том что любая проверка в GDScript - просто убивает любую возможность писать кастомные алгоритмы (там не особы много было проверок, чтобы каждая давала нагрузку в 100%, примерно).
В любом случае ты показал, что проблема все равно есть (а не я затупил). Так что не вижу смысла в писькомерстве, просто это не совсем та задумка была (не размазывания данных по ленте).
PS
>видео
Когда пренебрегаешь проверками в костюмных алгоритмах.
>Твоя проблема - в вызовах функций
Вызов функции, сравнение int'ов - это все безумно быстрые операции. Но не для GDScript :)
>Я её по-быстрому накидал, вряд ли это подойдёт твоей игре
Почему не можешь кинуть в pastebin.com или подобное хранилища?
Сорцы гораздо приятнее читать из редактора тем более пользоваться деббагером построчно мы научились
Как ты странно переносишь на новые строки.
А питоновская обратная косая черта же работает?
operator \
operator \
operator \
>в том что любая проверка в GDScript - просто убивает
не в проверках дело, тебе правильно сказал >>1106467
>Твоя проблема - в вызовах функций.
Если ты будешь обращаться к Packed классу напрямую, через оператор [], как ты делаешь с Array[Array] то он будет быстрее, ровно как если ты обернёшь
>t[y][x]
в функцию, то время Array заметно вырастет
>Думаешь там Vector4 просто от балды
От не понимания тобой, что если тебе надо хранить 4 целых числа, то структура с четырьмя числами с запятой тебе не подходит, несмотря на то, что в ней ТОЖЕ 4 "поля" и выгоднее хранить в PackedInt*Array/PackedByteArray, в последнюю можно упаковать твои данные в 3-6 байт, в зависимости от данных ("Data Oriented Design" - Know your data)
По функции с pic3 я бы предположил, что бы джавист и рекомендовал бы как-то отделить эти сакральные знания от GDS, когда ты говоришь что функция возвращает класс и второй строкой не возвращаешь ничего, а последней self что всё в корне глупо, а если ты хочешь проверок, то тот же resize(), как и многие другие функции, возвращает результат, который, если хочется, можно проверять, а вот resize(0), который у тебя идёт ошибкой, - вполне обычный способ очистки структуры данных/массива
В любом случае GDS не для каких то быстрых алгоримов сделан, а чтобы код работал и на ПК и в телефоне и в браузере без ебли с компиляцией под каждый процессор и чтобы even kids can code
Скажи спасибо, что я тебе этот скриншот прямо из редактора кода скинул, а не открыв .gd в Блокноте со шрифтом Comic Sans. Учись читать код без СДВГшных привычек тыкать куда-то курсором мыши/стрелками. Дебаггер вообще забудь - дебаггер у тебя в голове, а дебаггер в компе только для калибровки головы.
Алсо, текст со скриншота легко распознать, если ты обязательно хочешь Ctrl+C/Ctrl+V, а не набирать его собственными руками с пониманием всех строчек. Рекомендую всё же стараться набирать код руками - мышечная память тренируется и ты будешь знать необходимый код даже лучше родного языка.
>>1106471
Обратная косая черта бесит, поэтому стараюсь её не использовать - есть же скобки, их можно переносить спокойно и в любом месте. Но вообще, тот скриншот специально причёсан, чтоб умещался в 80 символов с минимальным количеством лишних строк. Убрал избыточные объявления переменных и комменты.
>не в проверках дело, тебе правильно сказал
Да сколько можно. Я же не первый день занимаюсь профилированием.
>Вызов функции, сравнение int'ов - это все безумно быстрые операции. Но не для GDScript :)
~6-8 вызова функции и 10 условий с целыми числами, не должны давать +400%
>Если ты будешь обращаться к Packed классу напрямую,
Ты не совсем понимаешь что такое Array[Variant] и сишный массив int[] (пускай даже в обертке Vector<int> с COW данными).
По аналогии это как спорткар против лошадиной повозки (в случае packed это спорткар, который тянет повозка).
>>1106467
Даже тут на пике разница 2х - что вызывает много вопросов к реализации packed
>От не понимания тобой, что если тебе надо хранить 4 целых числа, то структура с четырьмя числами с запятой тебе не подходит
Чел, я не могут тебе на GDScript тебе это доказать, но то что я сделал должно быть быстрее твоего примера в 4х3 раз. У тебя быстро не потому что алгоритм быстрее, а потому что ты буквально максимально выкинул GDScript и дергаешь крестовый API. Это не оптимизация, это спекуляция.
Размазывание по массиву это первый вариант, который приходит в голову когда думаешь что можно сделать с Packed
>когда ты говоришь что функция возвращает класс и второй строкой не возвращаешь ничего, а последней self что всё в корне глупо.
Пчееееел, это валидный код, это тоже самое что "retrun null" ты же видишь редактор не ругается. Вот поэтому вы код друг другу не кидаете, вы начинаете писькомерством заниматься, на пустом месте.
На самом деле лучше действительно явно указать, я согласен что явное лучше неявного и обычно я так не делаю. Мне в моменте тесто срочно понадобилось добавить выход и все что я смог в рамках гдскрипт - пробросить "if return". Редактор не отругал я видимо и забил.
В динамических языках, где есть исключения используют "claim" подход (пик2 и 3) для быстрой проверки аргументов. Я сначала так и написал, но из-за отсутствия возможности остановить скрипт без высера в stderr пришлось быстро проброску сделать.
Насчет non-null подхода, есть отдельный пласт холивара. Теперь "null safety" зумеры гоняют по коду полу-валидные данные, портя сами данные в БД (что в разработке куда страшнее, чем упасть с NPE и залогировать ошибку). Спасибо котлину за агрессивный маркетинг, они вернули проблему, которую победили лет 40-50 назад. зумеры еще NoSQL переизобрели, но вроде сейчас успокоились, эволюция разработки реально ходит по кругу
resize(0) - это ошибка, потому что в предметной области не будет сетки нулевой размерности. Это не контейнер, это система. И чем трахаться и делать еще 100500 проверок для пустого массива - мне проще (и правильнее) не пропустить ошибку.
>В любом случае GDS не для каких то быстрых алгоримов сделан
Слишком все плохо. Если сегодня не затрахаюсь, я сделаю сравнение свап-массива с прямым удалением. И если не будет разницы или вариант на скрипте будет медленней я на полном серьезе дропну гдсрипт.
>Скажи спасибо
>Учись
>Рекомендую
Ой иди нафиг токсичное мудло. Не умеют пользоваться дебаггером, зато строят из себя хер пойми кого.
Вместо того чтобы разшарить код в 2 секунды - сидеть склеивать изображения как шиз. Я в акуе с тебя. Давай чуток пониже ЧСВ планочку?
Вы настолько тут передрочили на себя, что даже демо проекты кинуть не можете (а это просто удалить папку ".godot" и кинуть архив)
>Обратная косая черта бесит, поэтому стараюсь её не использовать
Не придумывай свою херню, смотри гайдлайн. У гдсрипта нормальный парсер. То как ты переносишь скобки - тебя будут считать за ньюфаню (это ужасно).
Может, перестанешь своё фото на аватарку ставить? Стрёмно же...
>Даже тут на пике разница 2х
Там разница всего 1.3 раза, если сравнивать PackedByteArray с Array[int].
Разница в 2 раза, если сравнивать PackedByteArray с Array[Array[int]].
Вызов функции get_id(x, y) - это до 6 раз медленнее.
Если добавить 1 проверку - до 13 раз медленнее...
>Это не оптимизация, это спекуляция.
Лалка, тебе шашечки или ехать? Либо красивые классы с удобным API и проверками, либо СУПЕР-ПУПЕР ОПТИМИЗАЦИЯ АЖ ВЕТЕР В УШАХ СВИСТИТ КАК ЖЕ БЫЫЫЫЫЫЫЫСТРО АААААААААААААА ЩАС БЛЕВАНУ ОТ ТАКОГО УСКОРЕНИЯЯЯЯЯЯЯЯЯЯЯЯ... Это и есть причина, по которой преждевременная оптимизация - корень всех зол. Ты СНАЧАЛА пишешь красивый, но очень медленный код, определяешь, нужен он тебе или нет, вносишь какие-то правки в соответствии с поставленной задачей (травку распространять или там трупы зайцев искать), и только ПОТОМ ты думаешь, как это всё можно оптимизировать (переписать на C/C++ через GDExtension или сделать кастомную сборку движка со своим модулем на C/C++). НЕ НАОБОРОТ. Если ты делаешь наоборот - ты и оптимизацию нормально не сделаешь (скорее только замедлишь свой код, как в твоём примере), и игру никогда не сделаешь, потому что будешь ковыряться в своих оптимизированных до непонятного состояния кодах и забудешь, что ты вообще собирался делать с игрой. Или сделаешь, но выйдет дерьмо - не в том смысле, что медленно будет, а в том, что игрокам будет скучно или неприятно играть. Уж лучше сделать медленный говнокод на скриптовом языке, который оценят и полюбят, чем ковыряться в супер-быстром оптимизированном по кэшу процессора, но никому нахрен не нужном коде фундаментально-геймдизайно плохой игры.
>на скрипте будет медленней я на полном серьезе дропну гдсрипт
Правильно понимаю, что игру ты даже не планировал начинать делать?
>>1106492
>Не умеют пользоваться дебаггером
Я умею пользоваться, но не пользуюсь, потому что не допускаю ошибок, которые потребовали бы разбирать программу дебаггером по строчкам. Понимаешь, когда у тебя будет побольше опыта в программировании, ты и сам сможешь держать в голове все состояния переменных и порядок обращений к функциям. Это с опытом приходит. А новичкам - да, новичкам полезно несколько раз пройтись дебаггером по строчкам и впитать то, как работает компьютер (или конкретная среда разработки/интерпретатор языка). Но для опытного человека это всё равно что ехать на трёхколёсном велосипеде для малышей на работу вместо хотя бы велосипеда для взрослых.
>Вместо того чтобы разшарить код в 2 секунды
Тебе красиво сделали, чтобы тебе удобно было смотреть с мобилы, а ты ещё недоволен...
>даже демо проекты кинуть не можете
А у тебя даже "демо проекта" нет...
>То как ты переносишь скобки
Обычно я делаю как-то так:
>_ call_one(
>_ _ blabla1,
>_ _ sub_call(
>_ _ _ bla1, bla2, bla3,
>_ _ _ blablablabla4,
>_ _ ),
>_ _ blabla2,
>_ ).call_two(
>_ _ blabla1,
>_ _ blabla2,
>_ )
Вместо "_ " табы. Что не так?
Или тебе не нравится форма записи "(foo as bar).foobar()"? Скобки из-за оператора "as".
>тебя будут считать за ньюфаню (это ужасно)
У тебя самого ужасный код с отвратным форматированием, так что не тебе это говорить.
Алсо:
>строят из себя хер пойми кого
>Давай чуток пониже ЧСВ планочку?
>будут считать за ньюфаню (это ужасно).
У тебя страх быть воспринятым "ньюфаней", но с других ты требуешь "понижать ЧСВ"?..
>Если сегодня не затрахаюсь, я сделаю сравнение свап-массива с прямым удалением.
Не ну вы посмотрите на эту скотину
Все что вы знали о сложности алгоритмов - байткод GDSсript работает настолько медленно, что разница O(n) видна только на тысячных массивов.
Живите с этим.
https://pastebin.com/fikqyeDK
Тебе настолько нужно бороться за свою самооценку, что ты нашел какой-то дилетантский высер.
Это тоже самое что сказать что подсветка синтаксиса не нужна и вообще она мешает читабельности кода.
И я тебя уверяю - ты найдешь таких шизов.
Джаваребёнок со школы вернулся? Беги уроки делай, борда 18+
Тебе настолько нужно бороться за свою самооценку, что ты написал что-то про дилетантство анонимуса.
Это тоже самое что сказать что общение на форуме не нужно и вообще оно мешает разработке игр.
И я тебя уверяю - тут почти все такие шизы.
>>1106507
>Все что вы знали о сложности алгоритмов
О какой "сложности алгоритмов" ты говоришь, сравнивая несравнимое?
В "remove_at" алгоритм оптимально скомпилирован в машинный код из C++ кода движка.
В твоём "swap" тот же самый алгоритм интерпретируется в реальном времени буквально из текста.
Что ты сравниваешь? Интерпретатор с компилятором? Да, интерпретатор медленнее. И что теперь?
Смысл интерпретатора не в скорости исполнения кода, а в скорости разработки приложения...
>>1106512
Больше всего я кодил на вариантах Pascal, а Java я не пробовал. Только JavaScript чуть-чуть.
>>1106517
Зачем ты спамишь этими картинками? Игру делай лучше.
>СУПЕР-ПУПЕР ОПТИМИЗАЦИЯ АЖ ВЕТЕР В УШАХ СВИСТИТ КАК ЖЕ БЫЫЫЫЫЫЫЫСТРО АААААААААААААА ЩАС БЛЕВАНУ ОТ ТАКОГО УСКОРЕНИЯЯЯЯЯЯЯЯЯЯЯЯ
Кризис 1 сентября миновал, школота вернулась.
Ты за своей борьбой ЧСВ не видишь фундаментально проблемы.
Ппц, да кому не похер на сериализацию в плоский массив.
Просто выключи "борьбу" и внемли: Тебе в твоем коде чтобы добиться оптимизации - нужно написать не эффективный алгоритм - а выкинуть код GDScript, оставив только С++ вызовы. Вот в чем фундаментальная проблема.
>>Не умеют пользоваться дебаггером
>Я умею пользоваться,
>разбирать программу дебаггером по строчкам
Кек, ты даже даже не понимаешь основную роль дебаггера, о чем ты вообще говоришь.
>потому что не допускаю ошибок,
Ппц шиза, не иначе одарённый?
Конечно если ты не делаешь игры, у тебя не будет ошибок в коде - у тебя нет кода!
>Но для опытного человека это всё равно что ехать на трёхколёсном велосипеде для малышей на работу вместо хотя бы велосипеда для взрослых.
А ведь ты даже не понимал, что в момент ошибки - редактор перехватывает ошибку и включает дебаггер с трассировкой стека и контекста (ты даже можешь продолжить, потому что это перехват). То есть, разработчик заранее сделал эту фишку доступной по умолчанию и ты реально словно ребенок катался на трех колесиках не замечая, думая что равновесие держишь ты сам.
>Понимаешь, когда у тебя будет побольше опыта в программировании
Чел мне настолько похер на всю эту херню. У меня 20 лет опыта промышленной и около промышленной разработки. Мне мериться больше нечем. Я только по обстоятельствам не знаю все тонкости годота/геймдева, потому что играюсь с ним в свободное время. И уж точно я не буду доводить это до уровня какой-то работы (или изучать все подряд чтобы меряться со школотой на двачах). Так уж вышло, что айтишечка сложная область - у кого-то одни знания, у кого-то другие знания - это абсолютно не важно в рамках беседы. И я всегда вежлив пока вы не опускаетесь до писькомерства. Тебе похер на меня так же, как и мне на тебя. Перед кем ты пытаешься самоутвердиться? Зачем? Брось - просто наслаждайся разработкой.
>Что ты сравниваешь?
Есть такие умные книжки "алгоритмы и структуры данных" - найди, поможет понять о чем умные дяди пишут.
> кодил на вариантах Pascal
Как же стыдно быть паскалистом теперь, когда в треде сидит такой кринжовый ребёнок-переросток.
А ты видимо не целиком читал. Когда говорят O(N), это скоращение от t = O(N)•C, то есть нпдо домножить на время одной операции.Если у тебя два одинаковых алгоритма, то реальное время у C++ все равно быстрее, потому что у него C меньше. На кпждую операцию выполняется в разы меньше ассемблерных инструкций.
>не видишь фундаментально проблемы
Ок. В чём эта "фундаментальная проблема"?
>чтобы добиться оптимизации - нужно выкинуть код GDScript
Ок. А проблема-то твоя в чём? Конкретнее пиши, конкретнее.
>не понимаешь основную роль дебаггера
"Ты не понимаешь, а я-то понимаю, но объяснить не могу".
>>не допускаю ошибок, которые требовали бы разбирать программу дебаггером
>Ппц шиза, не иначе одарённый?
А ты у нас слеповатый? Очевидно, что можно не допускать ошибку "игнорировать ТБ", например.
>включает дебаггер с трассировкой стека и контекста
Я сразу, не глядя жму F8, скрывая лишний GUI, и ловким движением руки фикшу баг в коде. А ты?
>у меня 20 лет попыта ололо промышленной разработки
Ну, а у меня 20 лет опыта сидения на форумах и обсуждения проблем таких ньюфагов, как ты, которые ВПЕРВЫЕ В ЖИЗНИ обнаруживают, что СКРИПТОВЫЙ ЯЗЫК В Н Е З А П Н О МЕДЛЕННЕЕ C++, ВЫ СЕБЕ ЭТО ПРЕДСТАВЛЯЕТЕ??? НИКОГДА ТАКОГО НЕ БЫЛО И ВОТ ОПЯТЬ СКРИПТОВЫЙ ЯЗЫК МЕДЛЕННЫЙ! ВО ДЕЛА! ЗА ДВАДЦАТЬ ЛЕТ ПРОШИВАНИЯ ПРОМЫШЛЕННЫХ СТАНКОВ НА ЯЗЫКЕ 1С:ПРЕДПРИЯТИЕ НЕ БЫЛО НИ ОДНОЙ ПРОБЛЕМЫ СО СКОРОСТЬЮ СКРИПТОВЫХ ЯЗЫКОВ, А ТУТ ВОТ ТЕ НА - ТОРМОЗИТ СИЛЬНЕЕ, ЧЕМ C++?!?!?! WTF!!! Э... Э... ЭТО ВСЁ ДВИЖОК ВИНОВАТ!!! ФУ! ПЕРЕХОЖУ НА C++, СРОЧНО!!! БУДУ ПИСАТЬ СВОЙ МИКРО-ОПТИМИЗИРОВАННЫЙ КОД СО СКОРОСТЬЮ УЛИТКИ, НО ЗАТО КАК БЫСТРО ОН БУДЕТ ЛЕТАТЬ!!! ВСЕ ИГРЫ МИРА СКЛОНЯТСЯ ПЕРЕДО МНОЙ!!!
>таких ньюфагов, как ты, которые ВПЕРВЫЕ В ЖИЗНИ обнаруживают, что СКРИПТОВЫЙ ЯЗЫК В Н Е З А П Н О МЕДЛЕННЕЕ C++
Кстати, интересный факт: у нас тут примерно раз в полгода-год эта тема с прогонами Array в for всплывает. Стабильность!
Всем спасибо за обсуждение - размялись, выяснили, какие массивы юзать, отдохнули - теперь можно и игры делать! Так?
Когда ты пишешь код в таком стиле, это скорее попахивает нитакусиком анархистом, а поэтому, вме остальное написанное тоже уже воспринимается через призму - может и там шиза. Ньюфаги хотя бы могут еще переучиться на бест практики.
Туда же аплоиб в духе - скажите спасибо что скриншот показал. Ла просто сказал бы - а, аам код удобно, вот я к скриншоту еще и ссылку на сорцы добавлю.
Так! Всех школьников собрать в актовом зале. И подготовить ебальники к осмотру!
Еще они будут Батяне про алгоритмы что-то рассказывать.
Как я во время протестил, даже "mono" просто защеку дает.
>попахивает нитакусиком
>воспринимается через призму
http://ru.wikipedia.org/wiki/Предвзятость
>а, вам код удобно, вот я к скриншоту еще и ссылку на сорцы добавлю
Ты на анонимном форуме и никто не знает, что перед тобой нужно ковровую дорожку выкатывать, ботинки вылизывать и в попку целовать, так что можешь не пытаться качать права. Ты просил пример кода - тебе дали пример кода. Картинкой или ссылкой на какую-то сраную файлопомойку - какая разница? Могли ведь и просто не отвечать на твой пост - пройти мимо, заниматься своими делами, а ты бы сидел и ждал у моря погоды. Нет, нужно начать качать права в духе "ты не так дал, как мне хотелось, поэтому извинись и дай снова, но как я хочу" - и ты ещё что-то там про "пассивную агрессию" вякаешь, когда сам ведёшь себя откровенно по-свински.
То же самое со стилем оформления кода - стиль оформления зависит от принятых норм конкретной организации или конкретного лица, работающего в одиночку, потому что это не какие-то нерушимые законы языка. Тебе физически больно видеть перенос строки не там, где ты привык? Что ж поделать - учись читать чужой код, не все люди в этой жизни будут подстраиваться под тебя. Или опять будешь качать права "я хотел получить от тебя бесплатный код, но ты не там перенос строки сделал, поэтому извинись, сделай перенос строки в другом месте (в каком - не скажу), и скинь мне код снова"? Кто ты после этого? Просто свинья. Вот и жри, что дают.
>>1106557
>если собираетесь делать игру
А как это относится к твоим тестам? inb4 прибежишь жаловаться на то, какое же говно этот C# и его связка с Godot...
> inb4 прибежишь жаловаться на то
Знаешь, я раньше думал ты троллишь, но ты походу реально воспринимаешь мир так, как-будто только у тебя есть опыт в разработке, а все вокруг ньюфаги.
Нездоровая фигня если честно.
> C# и его связка с Godot...
Чуть дольше запускается игра на некропеке. Но удобство от IDE и великолепные шарпы нивелируют это
>прибежишь жаловаться на то какое же говно этот C#
Ты шутишь? Это один из лучших современных языков.
Я вообще думал что там корявое mono и на байткоде тоже будет шляпа.
https://www.reddit.com/r/godot/comments/1kzf4tn/why_godot_4_c_integration_is_still_called_mono/
Моя ошибка что я раньше не поднял эту тему, а прочитал местное нытье какой шарп плохой и решил отложить на потом пока играюсь с api, потому что на гдскрипте комфортнее ковыряться и он ближе к движку.
Чё дальше? Покажешь измериешь насколько быстро поиск работает в отсортированном массиве?
Конечно, знаем. Master ветку и писать код на c++. А не раздувать билд блоатом дотнета.
Причем, это было сказано еще до всех этих бенчмарков.
>писать код на c++.
Так ты и в С++ наговнокодишь. Как-будто С++ выпрямляет руки и дает какие-то знания в оптимизации. Скорее отстрелишь все конечности на UB и сигфолах
Нефига, я еще триплу выбил.
>Чё дальше?
Не знаю, предлагай - 4х стратежку может? Там еще больше циклоплясок.
>Это один из лучших современных языков
Ну давай разберём по пунктам твой язык:
- {скобачки} "как у C, но не C" бьют по глазам;
- доднет, который нужно отдельно (!) устанавливать;
- проблемы с любой платформой кроме винды (вендорлок);
- но даже на винде работает через пень колоду из-за сборки мусора;
- из-за чего приходится "оптимизировать код под сборщик мусора" - пипец очевидный.
Дальше можно не продолжать - это порождение Microslop сделано как Internet Explorer, и как IE умрёт.
>Но удобство от IDE
Это которая с привязкой к ДНК ануса пользователя? Или которую нужно самому из исходников собирать?
>потому что на гдскрипте комфортнее
Конечно же комфортнее, иначе им бы не пользовались так часто, а сидели на всяких костылях вроде C#.
>Жир с экрана потёк
На жире можно жарить... жарить игры. Бадум-тс!
>>1106576
>Не знаю, предлагай - 4х стратежку может?
Ты прокрастинируешь. Придумай игру, которую не нужно кодить. И сделай.
Который даже скачать нельзя
>Ну давай разберём по пунктам твой язык:
>{скобачки}
Какой же ты ньюфаня, страшные скобочки :)
>доднет, который нужно отдельно (!) устанавливать;
Пик1. Приходи ко мне, у меня уже стоит.
>проблемы с любой платформой кроме винды (вендорлок);
Пик2. Ты из криокамеры?
>- но даже на винде работает через пень колоду
На серверах под такой нагрузке гоняют, что твоей пеке не снилось.
>из-за сборки мусора;
А в гдсрипте нет сборки мусора? Или подсчет ссылок уже не ГЦ? Из-за природы графа постоянно линкуешься между собой (а я говорил что годоту ближе golang, там на уровне архитектуры такой проблемы нет).
>из-за чего приходится "оптимизировать код под сборщик мусора" - пипец очевидный.
Подписывайся на RefCounted, используй пулы, используй оптимизации шарпов (в отличие от квази языков у него есть инструменты). Но пулов тебе хватит.
>это порождение Microslop
Сейчас бы разделять корпоратов на хороших и плохих.
Последний дотнет весьма неплох. Есть и скрипты и AOT, сервер очень качественный (но мне не довелось прям глубоко пощупать). Если надумаешь делать сетевую игру - у тебя уже будет скилл шарпов с хорошим бекендом.
Скажи альтернативу для карманного языка для повседневного быта?
>Это которая с привязкой к ДНК ануса пользователя? Или которую
Какую хочешь. Начни с vscode.
>Конечно же комфортнее,
Потому что все делается под него. А не потому что питон-синтаксис чуть лучше говна.
Сделали бы шарпы first-class citizen проблем бы не было.
>Ты прокрастинируешь. Придумай игру, которую не нужно кодить. И сделай.
Тогда нужно будет много рисовать. А я хочу много кодить.
Вот такой крафт будет в игре, тупо бросание итемов в итемы, которые потом сами будут во что нибудь крафтится.
Щас ещё параллельно начал читать кровавый меридиан, и там судья чтобы скрафтить дымный порох, сикал на смесь серы и селитры, а потом мял, поэтому чет задумался, может тоже добавить сиканья, и использовать его например для крафта и привлечения внимания хищников но наверное не стоит.
Генерацией мира решил заняться чуть позже, как закончу с основными крафтавыми итемами патроны
Из-за таких как ты, которые качают и не делают игры - достойным людям не достаются доступные версии. И они потом сидят и ждут следующие версии в надежде что успею скачать.
Что ты вообще забыл в разработке?
С костром ты сделал, что деревяшки 1-2-3-4 стакаются, подумай, потянешь ли так-же делать всё остальное?
Сикать - хорошо, срать - тоже, даже харкать для получения амилазы, это то, чего нет в обычных играх.
>с первой попытки практически почти не требовались правки
Если правки требовались, то это не с первой попытки. Ну ИИ сам себя всегда нахваливает.
А у меня стакаются конкретные предметы, поделенные на условные тиры. Т1 деревяшки стакаются в т2 деревяшки, к т2 деревяшке можно кинуть т1 уголь и получить снова костёр, либо другой конкретный ресурс, эти все имена прописываю в экспортный массив самих предметов. В целом кажется понимаю о чем ты, можно запутаться во всех этих стаках, посмотрим, но думаю при приемлемом количестве крафтовых ресурсов всё будет нормально, ну и прям бурится в длинные цепочки не буду.
>Сикать - хорошо
Да, тоже иногда так думаю, в зависимости от пола можно ещё либо вперёд стрелять струёй либо взад. Посмотрим в общем
На самом деле может оказаться очень неплохим тот факт, что многомиллиардные компании пытаются выдать ЛЛМки за ИИ и AGI. В будущем интернет может залить нейрослопом прям совсем и будет очень сложно отделить правду от ложи.
И, тем временем, тот кто разработает реальный AGI, получит возможность выйти на вершину пирамиды, пока дураки будут тыкаться в ЛЛМки. Потому что его системы будут и задачи реальные решать, и требовать не очень дорогого железа. А те же дурачки будут постоянно навешивать логику ЛЛМок, даже если найду сорсы.
В общем, если вы думали отсидеться в GDScript и потом переписать узкие части на шарпы, то не выйдет.
Вероятно годот перевод C#-класс в байткод GDScript и класс превращается в кактус.
Вот такие мосты ценой производительности 40 порядков.
Страшно.
PS Как же плохо гпт чат переводит код из гдскрипта в шарпы, как вы там вообще вайбкодите, нереальная шляпа.
>я проверил задумку.
Твоя Remove() ничего не удаляет кроме уменьшения твоей переменной, память ты не освобождаешь, не позорься
Самое забавное, что тоже самое, скорее всего, будет и с gdextension c++. То есть, там же тоже будут мосты. Причем нельзя сделать какой-то медленный фасад и ядро отдельно. Все что касается ГДСкрипт все превращается в ГДСкрипт по цепочке.
Это как Мидас, только не в золото превращает :)
Так что либо тоже фулл на плюсах делать. Либо уже в движок.
>память ты не освобождаешь,
У тебя профдеформация от скриптов. Я там буквально переписываю ячейку памяти. Я словно Гарбейч Коллектор, Повелитель Интов, Владыка Списков! - беру и переписываю мною контролированное 4 байта в памяти.
Внимательно вникни в этот алгоритм. Очень хороший алгоритм (Альтернатива linked list), когда не важен порядок и нужно частое добавление удаление по стоимости O(1) поэтому такие космические результаты в нормальном тесте
Если что этот алгоритм хорошо подходит чтобы хранить всякие предметы на карте - например морковка или общее - еда. Пройтись по списку и замерить расстояние будет дешевле чем по всей карте.
На, изучай
https://pastebin.com/UqMpc8g2
В смысле, ты решил, что надо маршалить по вызову на каждый элемент массива?.. Чел, ну идея же в том, что модуль считает всю игровую логику, а потом передает ее для рендера. Практически MVC.
Так это было известно еще с того блогпоста про рейкасты в C#.
>Так это было известно еще с того блогпоста про рейкасты в C#.
Там была проблема в том, что статические типы маршаляться в variant. Это проблема между статик язык -> api.
А то что происходит на стыке гдскрипта и С# это вообще безумие. Так что те кто мечтает что под конец перепишет свои узкие части на GDExtension C++ можете забыть об это влажной мечте (либо переписать все на С++)
Ну то есть сделает то, что я говорю из треда в тред - не берите C#, гдскрипта вам будет хватать для 99% игр, берите c++ если у вас вдруг уникальная игра про 10000+ юнитов которой гдскрипта или нод перестало хватать.
Как раз из всего этого можно сделать вывод, что если ты программист и планируешь в своей игре делать много кода вне взаимодействия с API - берите только C# и не в коем случае не смешивайте шарп и гдскрипт. Стройте алгоритмы на шарповых типах, максимально стараться избегать годот типов, то есть минимизировать контакт только до взаимодействия с API.
>- доднет, который нужно отдельно (!) устанавливать;
Он вроде идет вместе с дотнетом? Просто у меня есть дотнет, я не знаю откуда дергается (нужны опытные дотнетчики с пояснениями).
>- {скобачки} "как у C, но не C" бьют по глазам;
Главный холивар 2-3 пик
>страшные скобочки
От них глазам больно. Скипнул c/c++ в 00-х/10-х и не планирую использовать их ни для чего кроме особо производительного кода. Так и зачем c# нужен, лол?
>Пик1
Ненавижу эту шизу микрослопа. Зачем они высирают огромное количество версий? Почему виндувс10 стал весить в десятки раз больше старых версий, хотя его функциональность не поменялась с, наверное, вин95? Индусский код - бессмысленный и беспощадный... Но пользоваться линуксом всё ещё невозможно...
>Пик2
Это какая платформа? Приходи, когда установишь микрослоп на какую-нибудь Plan 9 или что-то вроде. Скомпилировать Godot без микрослоп-шизы можно практически куда угодно, хоть на микроконтроллер (подрезать придётся немного, но это не страшно).
>На серверах
Молодой человек, это не для вас разработано. Там буквально тысячи ядер под одной крышкой CPU, терабайтами измеряется RAM одного блейда и уже петабайтами - постоянная память SSD в блейде. Т.е. заявление "это язык для серверов" - это буквальное признание поражения в плане производительности.
>А в гдсрипте нет сборки мусора?
Нет, в GDScript нужно дёргать queue_free()/free().
>Или подсчет ссылок уже не ГЦ?
Подсчёт ссылок - это подсчёт ссылок. Когда ссылка удаляется, объект освобождается. Он не становится "мусором", и его не нужно "собирать" - то есть язык обходится без "сборки мусора". Суть GC в том, чтобы дождаться, когда вся RAM засрана мусором, и тупо застопорить выполнение кода, пока идёт чистка. Это основная причина всем известных тормозов Unity, отсутствующих на движках типа Godot, UE и т.п. И тут бессмысленно спорить, сами Unity Technologies это признают и рекомендуют оптимизировать пулом:
https://docs.unity3d.com/6000.0/Documentation/Manual/performance-reusable-code.html
>This helps minimize garbage collection (GC) overhead and reduce load on the CPU.
Напомню, что именно Unity популяризировала C# (в геймдеве как минимум - всякие мелкие фреймворки рассматривать смысла нет, после выхода Unity они неактуальны и используются только по фану). Т.е. распространители C# открыто признают косяк C#.
>карманного языка для повседневного быта
А при чём тут Python? Мы же C# обсуждали...
>>1106725
Дотнет устанавливается виндой в фоне, раздувая установленную версию где-то мегабайт на 100-300 в результате каждого мажорного релиза, потому что совместимости между ними нет и ты должен иметь одновременно все версии, чтобы весь софт работал. Естественно, это плохо, и так делать нельзя. Лучше запускаемый файл 1 приложения весит +3 МБ как у FreePascal с LCL из Lazarus, чем вся винда имеет аж несколько гигабайт какого-то нейрослопового кода, требуемого для запуска 1 КБ вирусни из интернета. Забавнее всего то, что Калькулятор и прочие такие приложения ЖИРЕЮТ и тормозят с каждым таким обновлением - на них обкатывают всё это дерьмо.
>Главный холивар 2-3 пик
Да фигня это всё. Хоть в одну строчку пиши, хоть без отступов сплошной портянкой: вся суть "операторных скобок" в том, что программисту не нужно думать, как форматировать код - форматирование можно на 100% автоматизировать. Но... Зачем? Часто тебе нужно форматировать чужой код иначе, чем он уже есть? Ты используешь отступы и переносы строк, потому что УДОБНЕЕ с ними, чем без них. Так почему б не делать значимые отступы как в Python/GDScript и выкинуть операторные скобки совсем? Это же куда более естественно, чем добавлять бессмысленные отступы, бессмысленные переносы строк и прочее, которые автоматизируются скобками. Единственный минус значимых отступов - труднее копипастить код, и в особенности чужой код, но копипаста - антипаттерн, следовательно, это даже не минус, а плюс: защита от дебилов с рефлексом на ctrl+c/ctrl+v. А все, кто будут защищать скобки - они и есть, судя по всему.
>если вы думали отсидеться в GDScript и потом переписать узкие части на шарпы, то не выйдет
Что, 20 лет 1С: Предприятие тебя этому не научили?
Внимательно следи за руками, показываю один раз:
1. Пишешь свой цикл в цикле в цикле на GDScript.
2. Играешься с ним, спрашиваешь: фан есть/нет?
3. Если надо, что-то там меняешь в своей логике.
4. Когда чувствуешь фан, делаешь эти замеры.
5. Видишь узкий участок (цикл в цикле в цикле).
6. Рефакторишь его на C через GDExtension...
7. ???
8. Получаешь все профиты мира геймдева.
А что сделал ты?
1. Написал какой-то велосипед на C#.
2. Написал цикл в цикле в цикле на GDScript.
3. За каким-то хреном зовёшь C# из этого цикла.
4. Жалуешься, что ты до сих пор безыгорный (???).
WTF? Можешь ли ты стать ещё жирнее, интересно?
То есть, годот не "красит" все кишки, проблема только на стыке глобального класса (не путать с синглтонами, [GlobalClass] это другое - это связь со скриптом).
Глобальный класс получается чуть тяжелее на уровне погрешности измерения (2 и 3), но все еще ощущается аромат производительности шарпов (4).
Так что смело говнокодьте. Если хватит мозгов можно будет вынести отдельно тяжелые алгоритмы.
Но если вы уважаете себя как программист - работайте сразу через шарпы. Не так удобно, зато вы не платите микросекундами за то что стоит наносекунды (то есть не платите за банальные операции 1000-10.000 дороже).
Вот такие дела, годотики. Всем чмоки в этом чатике.
Ты слишком тупой чтобы понять что это не была оптимизация. Это был умышленный замер стоимости маршалинга между C# <-> GDScript.
Лучше бы не пытался думать, а спросил что дядька делает такое странное.
Давайте еще раз напишите, что я в цикле дергаю сгенерированный мост, вы же тут ппц умные.
Вы как тот абориген, который видет трансформатор - осматриваете и ухмыляетесь - этот человек сделал коробку чтобы она гудела, какой же он тупой.
> если вы думали отсидеться в GDScript и потом переписать узкие части на шарпы, то не выйдет
Мы ето думали до 2023 года, самые слоупоки думали до 25-го. Сейчас уже самому дураку ясно, что вопрос кодинга закрыт в принципе. Ты художник, ты делаешь свой арт-проект, не беспокоясь о коде. Почему? Потому.
>Я не говнокодер, я художник.
Это я и так знаю, но что мешает взять сразу нормальный язык и не платить за вызов фунции микросекундами? Шарп как раз поможет немного выпрямить руки и подружить с Си синтаксисом.
> но что мешает взять сразу нормальный язык и не платить за вызов фунции микросекундами?
Да действительно. Почему бы и нет?
>Ладно, я был импульсивен
>>1106745
>Это был умышленный замер
Ахаха, как же тебя корёжит, лалка.
>зато вы не платите микросекундами
А о времени разработчика ты не подумал?
>>1106747
>Ты художник, ты делаешь свой арт-проект
База. Без художественной части игра - не игра.
>>1106751
>не платить за вызов фунции микросекундами?
Дурачок, ты же платишь ЧАСАМИ за НАБОР кода...
>>1106759
...или ТОКЕНАМИ, что ещё дороже и опаснее в итоге.
> нормальный язык
> берёт кресты
>>не платить за вызов фунции микросекундами?
>Дурачок, ты же платишь ЧАСАМИ за НАБОР кода...
Какие часы дебил?
Разница:
if condition:
if (condition):
callMethod()
callMethod();
>или ТОКЕНАМИ
>Будьте снисходительнее я вайбкодя.
Понял, прости за наезд.
Да ты конечно можешь брать C# и дальше и удивляться каждый раз, когда опять что-то пойдет не так.
>Разница
Хорошо ты сам себя приложил, молодец.
GDScript всё-таки топ - даже C#-раб подтвердил.
Контроллер персонажа в кадре обычно один. Поэтому смело бери гдскрипт - я делал и мультиплеер игры, там вероятность что ты упрешься в скорость практически нулевая.
Весь дроч на все эти пулмассивы, ecs, безнодовость и прочее важны только когда у тебя 10000+ объектов. Когда у тебя 1 или 16 - вообще неважно. Ты уложишься в кадр даже с говнокодом, а значит инпутлаг не внесешь.
Чтобы можно было помимо билда под браузер нормально билдить игру для пека в экзешник без оборачивания в электрон с его +200 мегабайт веса
Че там в годоте с этим?
Официальный релиз может ток вебгл2
Но есть ещё вот этот форк
https://github.com/dwalter/godotwebgpu
Кто-нибудь пробовал?
Как оно?
>Контроллер персонажа в кадре обычно один
Следите за руками:
1. Контроллер игрока один => это синглтон
2. Синглтон глобален => имеет доступ ко всему
3. Доступ ко всему сразу => удобство для кодера
4. Удобство для кодера => большая свалка кода
Вывод: контроллер игрока == весь код игры
Значит, не зря додиезер трясётся?..
>вебгпу
Зачем тебе именно вебгпу? Он же тормозит/глючит.
>электрон с его +200 мегабайт веса
Базовый Godot на Windows не меньше 50 МБ весит.
Для веба, нужно сжимать сборку, ≈10 МБ что ли...
>есть ещё вот этот форк
- форк версии 4.6, а сейчас уже 4.8 готовится;
- сделан вайбкодером ≈ нет понимания кода;
- не видно обновлений мастера уже 4 месяца;
- заявлена поддержка только на макинтоше.
Сам как думаешь? Стоит пробовать или нет?
>Зачем тебе именно вебгпу? Он же тормозит/глючит.
Мне нужон таа изкаробки. Шоб красиво было. Без вебгпу таа не будет. Во всяком случае я не знаю примеров наличия таа в реализациях на вебгл. А еще в вебгпу многопоток с вебворкерами делают без sharedarraybuffer и оно работает в обход COPM.
>- заявлена поддержка только на макинтоше.
Всё, вижу. Нахуй этот форк. И годот тоже нахуй.
>парочкатон
Как тебе "шизлонг"? Как шезлонг, но шизлонг.
Шизлонг = "шиз" - раскалывать + "лонг" - длинный.
Шизлонг - это десятки тысяч строк в одном файле, включающие в себя всю логику игры, которые по недоразумению называются "плеером", отвечая за совершено не связанные логически части игры.
Шизлонг как God Object, только длиннее и шизовее.
>>1106788
>таа
>красиво
Выбери что-то одно.
>Нахуй этот форк. И годот тоже нахуй.
Прощай. Желаю тебе сделать красивую игру без таа.
Апи контроллера один в один как если бы был на гдсрыге.
Только нейронка везде длинные имена раставила.
Может только подключение сигнала кажется странным, на делегатах. Зато теперь у нас есть человеческие лямбды!
Timer myTimer = GetNode<Timer>("Timer");
myTimer.Timeout += () => GD.Print("Timeout!");
>Мне нужон таа изкаробки.
Спроси в другом треде, ответ может быть не в рамках годот треда.
>Мне нужон таа изкаробки.
Спроси в другом треде, ответ может быть не в рамках годот треда.
>Желаю тебе сделать красивую игру без таа.
С чем? Фксаа? Он еще более мыльный
Мсаа тяжелый
А совсем без аа лесенки
>Timer myTimer = GetNode<Timer>("Timer");
Какая же мерзость... И всё это ради 1 ноды.
>+= () =>
Щас блевану, прекрати...🤢
Да уж, { } не самая главная проблема в C#...
>>1106794
>лесенки
А что в них такого, что нужно включать гостинг?
Насколько я помню, тяжелые только всякие MSAA x4/x8, а MSAA x2/ MFAA практически бесплатны.
>А что в них такого, что нужно включать гостинг?
В стилизации с цел шейдингом аутлайн смотрится всрато из-за лесенок
Гостинг в данном случае не мешает
var myTimer = GetNode<Timer>("NodeName");
Зато сразу видно что это запрос сервис локатора. И человек трижды подумает использовать ли его в кадре. А художники просто дёргают так:
$NodeName.method()
Он же художник, зачем думать.
GetNode<Timer>() Ну и как минимум это настоящая типизация на дженериках, а не хинты типов.
>() => {}
Лямбды это лучший подарок инопланетян человечеству.
Петухоне не используют лямбды, потому что в его синтаксисе они выглядят уродски. Но раз ты заикнулся про С++ - привыкай к синтаксису Си господ, расширяй кругозор.
>>1106759
Забавно что на родном С++ языке нужно в ручную биндить имена. Как же они клали болт на GDextension, просто невероятная затычка для галочки.
Мол
-смотрите у нас есть поддержка всех языков,
-только вам нужно будет самому вставить себе костыль в задницу.
-не, не, не, глубже вставляй, вот так, теперь проверни немного.
>Лямбды это лучший подарок инопланетян человечеству.
Скорее, вебмакакинский способ получить трудно поддерживаемую лапшу.
Если ты обрабатываешь событие функцией, ты можешь найти и изменить все использования по имени функции. Если у тебя лямбды - удачи пропустить где-то одну незаметно.
> нужно в ручную биндить имена. Как же они клали болт на GDextension
Что ты вообще пытался сказать?
>ты можешь найти и изменить все использования по имени функции. Если у тебя лямбды - удачи пропустить где-то одну незаметно.
Ты не сильно понимаешь что такое лямбда, да?
>>1106819
>Что ты вообще пытался сказать?
То что надо писать свой кодогенератор для биндинга. Ты же не хочешь писать такую портянку руками?
1 Пик - С++ здорового человека
2 Пик - С++ курильщика
В общем, из-за того что годот заточен под динамичный гдскрипт, нужно выполнить двойное сальто с поворотом. Я не эксперт в плюсах, но через C/C++ ABI было бы все проще (и проще было бы для всех типизированных языков).
Просто возьми и пофану почитай про шарпы. Не ради того что перейдешь на них, а чтобы расширить кругозор.
Я видел тут анона, который говорил что котлин использует.
Это конечно вендерлок на джетбрейнс, но смотри как визуально ближе он гдсрипту.
https://www.youtube.com/watch?v=Td7JbrGGa8o
Не хочу сказать что надо на котлин переходит, просто говорю про расширение кругозора. Шарпы все равно фичастие для геймдева, у них есть велью типы со структурами
>- проблемы с любой платформой кроме винды (вендорлок);
Если смотреть на лицензионный момент, ты сейчас шарпы свободнее чем джава.
Понятно кто "её танцует", но в случае чего может смело появится моно2 и подобное. Так что без шарпов ты уже не останешься.
Кодогенератор не знает, какие поля ты захочешь выставить, а какие нет. И не всегда угадает тип. В результате до подобной разметки и дойдешь. К тому же это будет засунуто где то в h файл и не отсвечивать.
>Что тебе не понятно в описаном недостатке лямбды?
Что ты написал ровно противоложную фигню.
Лямбды чаще используют как одноразовые обертки в flow кода, что бы как раз не создавать лишних одноразовых методов и улучшить построчного чтения.
Кроме котлина, там на эти лямбдах и правда все кишки торчат.
>Так все сидят на openJDK, а не oracle
Многие ставят с сайта оракла даже не зная этого. У них разрыв шаблона, когда узнают что их джава проприетарная, а злые шарпы наоборот открытые.
Это отдельная кухня мира джавы со своей драмой.
>Кодогенератор не знает, какие поля ты захочешь выставить, а какие нет
Остальные языки используют аннотации. Я думаю можно придумать спец комментарий.
В основном если ты пометил класс - то публичные методы ты хочешь забиндить, а приватные не трогать. Не так и сложно.
Про типы не понял, у нас же типизированный язык.
Проблемный сценарий такой. Ты написал в 4 местах репгируя на что то лямбду- sprite.position.x += 2. А потом передумал и переделал на += 2, но заметил только часть из них. Может, пропустил пробел и поиском не нашел. В релиз пошел баг.
Если ты пихаешь код в лямбду, который являет повторяющейся логикой приложения (объективно функцией) - ты просто тупой.
Это из серии - я посрал в штаны - почему теперь в моих штанах гдскрипт?
Теперь как в документации надо показывать пример на C# 😜
К сожалению у шарпов свой LINQ, я тоже больше привык к ФэПэшным map, filter, reduce
Просвещайтесь.
https://chickensoft.games/blog/game-architecture
И что было даже 3 года назад. Это типа коуп такой?
>Бля у людей такие странные предъявы, что оказывается ии не генерит на уровне ааа оравы художников, хотя оно уже щас моггает 99% контента в сфере.
>И что было даже 3 года назад. Это типа коуп такой?
А нахуя оно это всё надо? Инди хуйни на ассетах и до нейронок было предостаточно. Был дефицит полированного ААА, которое делали годами и тратили на разработку сотни миллионов. Ещё и повестка поднасрала, нагадив в хорошие технически проекты сомнительными сюжетными темами и дизайном персонажей.
ИИ была бы охуенной темой, если бы она могла сделать 1% самого сложного и редкого функционала в играх. А она наоборот делает 99% самого простого, которого до неё насрали предостаточно.
>>1106949
>Бля не в тот тред запостил, соре.
Всё нормально. Скоро на этой доске ничего не останется, кроме обсуждения нейронок.
Ну типа генерить сносного качества ассеты не боясь авторского права и то что эти ассеты в сотнях других играх уже были довольно круто и сильно облегчает жизнь как никрути.
Если анимации сделать то всё, можно клепать каждый месяц игры уровня елден ринга условного
>Всё нормально. Скоро на этой доске ничего не останется, кроме обсуждения нейронок.
Пускай они хоть конвейером будут делать ААААi игры. Я хочу сидеть на базовом доходе и клепать то что мне нравится. Честно говоря вайбкоди поднадоели.
>Если анимации сделать то всё, можно клепать каждый месяц игры уровня елден ринга условного
Нахуя? Тебе 4 абсолютно одинаковых игр от миядзаки недостаточно? Этого говна не просто дохуя. Его гигадохуя. Даже без нейронок. У огромного количества людей в стиме бэклог сотни игр. Они их никогда не то что не пройдут - даже не запустят. Чтобы их запустили, в играх должна быть солидная доза уникальности. А ты предлагаешь делать сейм щит пачками.
Не, если для тебя важен сам факт сделать и продать, то валяй. Но на хорошее отношение не рассчитывай.
Отдельно нужно поговорить про то, что тотальный клон елден ринга должен работать хотя бы не хуже оригинала. У оригинала пиздец какая отвратительная оптимизация на старте была. Чтобы такого не было, там месяц на одну только оптимизацию и тестирование должны уходить. Если кому-то всё ещё похуй и он с горящими глазами готов ринуться клепать подобный нейрослоп, то я искренне желаю этому челу сдохнуть обоссавшись кровью, когда толпа нейролуддитов будет пиздить его ногами посреди улицы.
> генерить сносного качества ассеты не боясь авторского права и то что эти ассеты в сотнях других играх уже были довольно круто и сильно облегчает жизнь как никрути
Дыа, двачую, у одного пожилого стримера, которого я смотрю, постоянно вот это: "чат, мы здесь были, я помню этот дом, чат, ты помнишь, чат, вон там за поворотом кухня и на столе корзинка с фруктами, а вот здесь телевизор, чат, ну?"
Ну раз ты тупой, то тогда, конечно, объяснять тебе что-то бесполезно. Я для умных пишу.
>>1106959
>клепать каждый месяц игры уровня елден ринга
Мечтаешь делать игры, в которое некому играть?
>Забавно что на родном С++ языке нужно в ручную биндить имена. Как же они клали болт на GDextension, просто невероятная затычка для галочки.
Они их и в движке биндят. А вообще - Clang AST, только - тсссс
В шарпах кодогенерация, вообще ничего не нужно делать.
>Clang AST
Причем тут AST дерево си? и причем тут вообще Clang с LLVM?
Любой вызов
С++ -> GDExtension-> API Godot
Будет дорогим, надо всегда помнить и не дергать API годота в циклах, то есть у тебя должно быть внутренние представление игры на языке, по типу
много_расчетов_и_циклов в C++/C# -> один вызов -> godot API
Пока в профайлере не видишь что твой код подходит к границе ресурса кадра, можешь вообще забить. Это головная боль игр с симуляциями или игр большим числом чего-либо.
> Любой вызов
> С++ -> GDExtension-> API Godot
> Будет дорогим
Вот этому заявлению требуется пруф.
>Они их и в движке биндят
>В шарпах
Я где-то хоть слово про шарп сказал? Или в движке есть шарпокод? Шарп вообще еще более жестко сшит с движком помимо gdext.
>Причем тут AST дерево си? и причем тут вообще Clang с LLVM?
А ты подумай. Поднапряги чуток мозг. Как же превратить AST в автобиндинг, хмм, таак, падажжи ебана
И дураку понятно что вызов платформенного апи будет дорогой, он в любом движке дорогой, кроме, может, ue и каких-нибудь моноязыковых движков.
>А ты подумай.
Тебе нейронка рассказала что такое кодогенерация, нам то зачем ваши совместные галлюцинации нести? Мы с тобой и так говорим в контексте этой самой кодогенерации. Употребление базвордов не делает тебя умнее.
И нафига я вообще стараюсь тебя понять??
О, ты соизволил таки почитать, уважаю стремление к знаниям
>Мы с тобой и так говорим в контексте этой самой кодогенерации
Не увидел разговора в контексте кодогенерации, увидел твое незнание как связана ast и кодогенерация и какую-то странную попытку перефорса безаргументным набором букв.
>Любой вызов будет дорогим, надо всегда помнить и не дергать API годота в циклах
Школотун, всё никак не уймёшься, что твой Hello World тормозит на целых 0.0001 наносекунды?
Или он уже завален домашкой и это кто-то другой вместо него отдувается в этом ИТТ треде?
>>1107097
>Вот этому заявлению требуется пруф.
Можешь для начала документацию почитать:
https://docs.godotengine.org/en/stable/classes/class_audiostreamgeneratorplayback.html#class-audiostreamgeneratorplayback-method-push-buffer
>This is usually more efficient than push_frame() in C# and compiled languages via GDExtension, but push_buffer() may be less efficient in GDScript.
>This is usually less efficient than push_buffer() in C# and compiled languages via GDExtension, but push_frame() may be more efficient in GDScript.
>>1107100
>Шарп вообще еще более жестко сшит с движком [чем] GDExtension.
Они в скором времени выбросят биндинги C# из движка, переделав его через GDExtension, и прекратят делать сборки движка с его поддержкой.
>Не увидел разговора в контексте кодогенерации,
Я первый и единственный кто употребил это слово к тому С++ бойлерплейту, брехливое ты мелкое нейронное чудо.
>>1107112
>как связана ast и кодогенерация
Когда упоминают кодогенарация всегда подразумевают работу через AST дерево (а как еще чудило? Через регулярки?). В этом ты и палишься. Проси нейронку генерировать ответ, иначе когда ты сам думаешь, то получается говно.
>>1107113
>Школотун, всё никак не уймёшься, что твой Hello World тормозит на целых 0.0001 наносекунды?
Да никто твой гдсрыг не трогает, рисуй дальше. Вместо того чтобы подымать проблему, будете всю жизнь долбиться в низкокачественный интерпретатор.
>>1107113
>Они в скором времени выбросят биндинги C# из движка, переделав его через GDExtension, и прекратят делать сборки движка с его поддержкой.
Вставить палки в колеса тем людям, кто по сути составляет реальный костяк разработчиков игр (потому что это те кто мигрировал) - весьма дальновидно. Ты сначала манишь конфеткой, а потом конфетку забираешь, это оценят.
>Они в скором времени выбросят биндинги C# из движка, переделав его через GDExtension, и прекратят делать сборки движка с его поддержку
Насчет скорого времени хз, это будет не раньше чем сьебется последний шарпист-мейнтейнер или не раньше чем с# таки сможет нормально через него работать
>Я первый и единственный кто употребил это слово к тому С++ бойлерплейту
Ты употребил его к шарпу, а потом не понял при чем ast к кодогену, хороший вопрос кто из нас двоих мыслит баззвордами не я уж точно.
>Когда упоминают кодогенарация всегда подразумевают работу через AST дерево
Не всегда, в шарпе и джаве например - это может быть работа по типам сборки и их содержимому, да и строго говоря - ast и кодоген не связаны ну никак, это две отдельных единицы работы, где одно может быть одним из источников данных для другого и не более. Лучше и правда пойди, подучи уроки, рановато тебе в геймдев.
Прости, что не сразу прокомментировал - срущиеся в треде отвлекли.
Система крафта прикольная, но у неё есть ряд проблем. Во-первых, в любой игре с большим количеством предметов рано или поздно возникает ситуация, когда два или больше разных предметов требуют один и тот же набор ресурсов, например, топор и кирка в Minecraft требуют три камня/слитка и две палочки, но расположенные в сетке крафта по-разному. Большинство современных игр с крафтом используют более простое меню крафта, в котором игрок просто выбирает желаемый продукт из списка и система автоматически берёт нужное количество нужных ресурсов из инвентаря, поэтому одинаковые рецепты друг другу никак не мешают.
Если же ты попытаешься сделать так, что каждый рецепт уникален, тогда у тебя могут получиться нелогичные или несбалансированные рецепты, когда игрок вынужден тратить больше ресурса, чем предполагает геймплейная стоимость предмета, или наоборот, не должен класть ресурс, имеющийся в игре и логически подходящий предмету, но из-за рецепта создающий какой-то другой предмет. На мой взгляд, баланс крафта куда важнее, чем какая-то уникальная механика крафта - вряд ли многие недовольны наличием GUI крафта в играх с крафтом (это стандарт жанра), но вот когда у тебя простой расходник требует больше ресурса чем другой расходник, и в итоге ты вынужден использовать второй только из-за того, что система крафта такая - это, думаю, многих бесит. Можно, конечно, придумать костыли... как с "тортом" в Minecraft, который предусматривает несколько использований в обмен на более сложный рецепт крафта... но костыли на то и костыли, что лучше обойтись без них.
Если ты попытаешься сделать важным порядок добавления предметов в рецепт (например, "камни -> доски" дают одно, а "доски -> камни" дают что-то другое), то это может оказаться сложнее для усвоения игроком, впервые знакомящимся с игрой, потому что мозг запоминает "порядок" хуже, чем "наличие"; в Minecraft сетка крафта позволяет разместить предметы в любом порядке, при этом можно заранее посмотреть, что получится (или нет) в результате крафта без потери ресурсов. А с какой-то версии они вообще добавили современный "крафт-список" с кнопками, автоматически расставляющими ингредиенты в сетке крафта - потому что большинству игроков неинтересно тыкаться в эту сетку и держать все рецепты в голове. Подумай сам, чем твой игрок будет больше всего заниматься - ради чего он пришёл в твою игру - и не будет ли система крафта отвлекать от этого?
Во-вторых... Я не сразу это заметил, но когда посмотрел ещё раз - ты сделал так, что предметы на земле сами стягиваются друг к другу? Сомневаюсь, что это удачное решение проблемы прицеливания. Собственно, проблема: игрок хочет что-то скрафтить, но промахивается, как быть? А если он хотел сделать два предмета одновременно, сбрасывая нужные ресурсы в две кучки рядом? Вот у тебя стопка дерева и стопка камня, будет логичнее сделать бросок сначала из одной стопки в две кучки, а потом переключиться на другую стопку и добить эти две кучи, чем делать по одной куче за раз, переключаясь между стопками чаще. Думаю, что возможным решением было бы подсвечивание кучи с каким-то отдельным шорткатом для добавления в кучу, например, если игрок нажимает левую кнопку мыши - создаётся новая куча, а если прицеливается и нажимает F - ресурс добавляется в уже существующую кучу. Но это, опять же, может быть не совсем понятно новичку...
В-третьих, вот ты крафтишь палатку прямо на земле - а если ты поставил её как-то не так? А если она оказалась не той стороной ориентирована? Её можно как-то передвинуть, или хотя бы разобрать без потери ресурсов и собрать заново? Пока ты тестишь механику на плоскости в пустом месте карты, она работает, но стоит карте стать более сложной и добавиться другим механикам - эта проблема может обостриться. Не зря большинство игр с крафтом физических объектов в мире игры предлагают что-то вроде объёмной проекции, показывающей, где и как будет расположен объект, до его установки. Можно считать, что это "мысленная проекция героя" (которую и реальные люди в жизни могут видеть перед глазами без каких-либо AR/VR-очков), если твой сеттинг не допускает никаких высокотехнологичных штук, то есть это не нарушает "иммерсивность" как обычный GUI.
Но главное, что, если твой объект будет слишком большим для места, куда игрок набросал кучу ресурсов? А если игрок впервые пытается скрафтить такой предмет и специально забрался в какое-то укромное место? Нужно его предупредить, что этому объекту нужно больше места... И желательно сделать это заранее, а не когда он уже навалил кучу ресурсов и теперь вынужден их подбирать и сваливать в другом месте. Какое-то автоматическое смещение объекта тоже не факт что будет удобным, особенно если объект смещается всё дальше и дальше от желаемого игроком места установки, или вообще толкает игрока/другие объекты.
А что будешь делать с мелкими объектами, вроде патронов? Крафтить по одному будет большой проблемой. Собирать по одному - тоже. Конечно, можно сделать так, что крафтится целый магазин из одной пачки пороха и одного кусочка свинца, но это опять же нужно балансировать, а не просто прилепить к игре "чтоб было".
Так что эта система вызывает массу вопросов и противоречий, из-за которых, возможно, придётся сову на глобус натягивать в совершенно других, не связанных с крафтом напрямую частях игры. Да и оценит ли игрок? В чём фан такой системы крафта для игрока?.. Вот поэтому такие системы крафта практически не встречаются в играх.
На счёт выделений организма игрока для крафта: смотри на свою целевую аудиторию. Кому-то будет неприятно настолько, что он напишет негативный отзыв и вернёт деньги. А кто-то посмеётся и напишет позитивный. Но если твоя ЦА к такому привычна и игра с порога заявляет себя как игра для любителей, скажем, чёрного юмора - то вероятность негативного исхода снижается, но ты платишь за это сужением возможной аудитории. Многие игры сегодня лишены чернухи не потому, что кто-то их заставляет, а чтобы максимально расширить свою аудиторию. Это уже больше вопрос маркетинга и монетизации игры, чем чисто геймплейных механик. Но с точки зрения самой механики - если крафт требует несколько разных действий с разными шорткатами на клавиатуре, это добавляет сложности, и эта сложность должна быть чем-то мотивирована, чтобы игрок не игнорировал эту опцию или чтобы не мучился слишком сильно, если эта опция безальтернативная и важна для остального геймплея (не заставляй своего целевого игрока делать то, что ему не нравится, не предлагая никаких альтернатив).
В общем, вот. Несколько дней хотел эти мысли записать. Удачи с игрой.
> в зависимости от пола можно ещё либо вперёд стрелять струёй либо взад
Есть уринаторы, с помощью которых пол, который сикает струёй взад может сикать и вперёд. Это тоже можно будет крафтить. Дополнительный геймплей.
>Прости
Да ладно!
>в любой игре с большим количеством предметов рано или поздно возникает ситуация, когда два или больше разных предметов требуют один и тот же набор ресурсов
>вряд ли многие недовольны наличием GUI крафта в играх с крафтом (это стандарт жанра)
>Подумай сам, чем твой игрок будет больше всего заниматься - ради чего он пришёл в твою игру - и не будет ли система крафта отвлекать от этого?
Вообще, крафт сам по себе не планируется как центровая часть геймплея, как в майнкрафте т.е. нельзя будет крафтить оружие, броню впрочем броньку впринципе можно, инструменты, и тп. Если говорить грубо, то я делаю шутер с интерактивным окружением и элементами рпг с прокачкой, выживанием и диалогами, поэтому и крафтинг будет более простым и линейным, оказавшись в лесу человек из доступных вокруг вещей мало что сможет сделать, условный костер, укрытие, еду, ловушку сварганит, и подорожник найдет для хила, для этих вещей сложные рецепты не требуются, важно скорее найти материалы.
>Если же ты попытаешься сделать так, что каждый рецепт уникален, тогда у тебя могут получиться нелогичные или несбалансированные рецепты
>Если ты попытаешься сделать важным порядок добавления предметов в рецепт (например, "камни -> доски" дают одно, а "доски -> камни" дают что-то другое)
Вообще к рецептам можно будет подойти с разной стороны, чтобы крафтить было легко, типа вместо 4 досок, использовать 2 доски и уголь. Сам порядок будет важен, но не для совсем "сырых" материалов, типа досок, железа у меня это будет сырой материал, добывающийся из ржавой техники, селитры и тп, эти предметы должны сформировать ключевые смеси которые важны для чего-то конкретного. В голове представляется такая линейная система с развилками. Запоминать цепочки будет тяжело поэтому не планирую их делать прям длинными, но думаю если человека постепенно погружать в систему, то со временем сможет и более сложные вещи крафтить, либо вообще использовать более сырые материалы, как слабую версию итема например человек хочет сделать взрывчатку, но ему лень или он не может довести рецепт до конца, поэтому он просто сбрасывать весь уже готовый порох на землю и стреляет в него, возможно даже с более разрушительным результатом.
>проблема: игрок хочет что-то скрафтить, но промахивается, как быть? А если он хотел сделать два предмета одновременно, сбрасывая нужные ресурсы в две кучки рядом? Вот у тебя стопка дерева и стопка камня, будет логичнее сделать бросок сначала из одной стопки в две кучки, а потом переключиться на другую стопку и добить эти две кучи, чем делать по одной куче за раз, переключаясь между стопками чаще
Вообще можно толкнуть телом, но думаю стоит попробовать замутить "хватание" как в хл 2, чтобы манипулировать предметами. А так притяжение скорее задумывалось как сигнал что предметы совместимы, и работает это не прям чтобы на большом расстоянии, поэтому можно создать недалеко друг от друга кучки.
>В-третьих, вот ты крафтишь палатку прямо на земле - а если ты поставил её как-то не так? А если она оказалась не той стороной ориентирована? Её можно как-то передвинуть, или хотя бы разобрать без потери ресурсов и собрать заново?
>Но главное, что, если твой объект будет слишком большим для места, куда игрок набросал кучу ресурсов? А если игрок впервые пытается скрафтить такой предмет и специально забрался в какое-то укромное место?
Честно говоря, пока так далеко не думал... Вообще разобрать уже впринципе можно, если всунуть скрипт, но она задумывалась как одноразовый предмет. Но щас так думаю, все таки стоит замутить что-то вроде хватания или толкания, чтобы игрок мог манипулировать предметами. И дать палатке хп для разбора.
>А что будешь делать с мелкими объектами, вроде патронов? Крафтить по одному будет большой проблемой. Собирать по одному - тоже
Сейчас мы как-бы крафтим сумки с патронами но можно будет покупать к одной категории стволов, которые можно вскрыть и получить аммуницию. Либо использовать саму сумку как условный осколочный взрыв пакет, который при детонации выстреливает снаряды в себе содержащие. Но это пока не реализовано
>На счёт выделений организма игрока для крафта: смотри на свою целевую аудиторию. Кому-то будет неприятно настолько, что он напишет негативный отзыв и вернёт деньги. А кто-то посмеётся и напишет позитивный. Но если твоя ЦА к такому привычна и игра с порога заявляет себя как игра для любителей, скажем, чёрного юмора - то вероятность негативного исхода снижается, но ты платишь за это сужением возможной аудитории
Ну вот да, это скорее про черный юмор, нежели прям необходимость усложнить крафт, поэтому наверное обдумаю это всё позже.
>В общем, вот. Несколько дней хотел эти мысли записать. Удачи с игрой.
Ну нормально ты так прошелся. Но пищу для размышлений по поводу всего этого дал. Спасибо!
>>1107139
Не православно как-то это всё
> Не православно как-то это всё
А, у тебя монах во скиту, а, пнятн.
При этом совсем не на тех 2 ядрах, на которых обычно чилится открытый Godot!
Как так? Вы это каждый день терпите, когда пишете код в своём любимом сидоте?
Алсо, почему в сидот-едишен Godot Editor нет подсветки сидоти? Как включить?
Вирусы с приставкой VS не предлагать, уже пробовал ставить - долго удалял...
#НЕДВИЖКОСРАЧ #КРИПТОМАЙНЕРЫ #СИДОТИВГОДОТЕ #МИКРОСЛОПНАСРАЛВШТАНЫ #ПАРАНОЙЯ
P.S. Перейду на C++, если этот фарм крипты сидотей не прекратится.
А ты нажимал эту кнопку? Донатил? То-то же...
А помнеш как тебе сто раз говорили не брать сишарп версию
> говорили не брать сишарп версию
В наступившем уже 3 года как веке нейрослопа проще давать нейронке конвертировать свой код в чистый си и компилировать нативные модули движка, и пересобирать свой движок со своими модулями.
>чистый си
Молодец, в батю пошел
https://www.youtube.com/watch?v=XHosLhPEN3k
> Молодец, в батю пошел
Я не мог пойти в батю, потому что батя слесарь я сам батя кодинга, нахожусь в профессии уже 30 лет, начинал с VB5, пересел на дельфи, оттуда на лазаря, потом шарп, и только в последние годы дорос до крестов.
И да. В посте опечатка.
>>1107351
> конвертировать свой код в чистые кресты
>в чистые кресты
Ну с чистыми сями еще можно кайфануть, от низкоуровневой.
А с зигом кайфануть от полного контроля.
Тут вот чел в том году наворачивал.
https://gamesbymason.com/blog/2025/zcs/
А про С++ ты не осилишь.
PS Маскот не шутка.
> С++ ты не осилишь
Нет ты.
Ладно что это уровня hello world, но это даже не твое. забей, это же ты школьник с движкосрача с паталогическим нарциссизмом? Как же классно общаться на анонимном форуме
Количество WTF/строку просто зашкаливает. Там тебе и using std, и stoi, и try/catch. и в принципе cout а не какой нибудь fmt
Нейронки обучены на тоннах говнотуториалов. которые нужны студентам проходить тесты по типу егэ
Угадал - я зашёл на microsoft.com ("маленький и вялый дот ком"), чтобы разобраться, чем занимаются шарписты. Вот эта ссылка, если тоже хочешь ознакомиться с их вкусами: https://learn.microsoft.com/en-us/dotnet/csharp/
>>1107340
Сам Godot лежал на 0%, а что-то вдруг начало бешено крутиться на обычно спящем ядре... после билда C#.
Ладно, я разобрался - это шедулер Windows шалит... Дело в том, что у AMD процессоров два CCD с независимым кэшем, и если какой-то процесс сидит в одном CCD, доступ к кэшу из другого CCD у него затруднён. Также парковка ядер позволяет экономить энергию. Поэтому Windows старается держать мелкие процессы на ядрах одного CCD, пока второй спит. Запуск Godot на это обычно никак не влияет, потому что у стандартного Godot мало потоков и они в основном бездействуют. А вот C#-билд Godot вместе с собой загружает экосистему C# и потом что-то бешено компилирует всеми доступными ядрами, из-за чего нагрузка взлетает - и, видимо, шедулеру Windows показалось, что будет лучше скинуть одно из моих нормальных приложений (браузер/плеер/торрент-клиент/что-то другое) на ядро второго CCD. Поэтому это нормальная нагрузка в необычном месте, и всё из-за этого наглого C# компилятора. Всю голову сломал, пытаясь понять, что же пошло не так, если нагрузка на CPU обычная, а её распределение по ядрам - внезапно нет...
>>1107348
Я купился на рекламу маркетолога выше по треду. Мне только пару массивов ускорить - всё остальное будет на GDScript, и куда-то релизить я этот код всё равно не буду, а C# показался чуть-чуть более доступным для теста...
An overview of the available language bindings for Godot & Co
https://github.com/Godot-Languages-Support/godot-lang-support
И самым первым идёт:
C++ / Godot module 💍 ⚙️ 🌍 ⚡
You can code your entire project (or parts of it) in C++ and include the game logic as Godot modules.
Думойте.
Скомпилировать.
>если тоже хочешь ознакомиться с их вкусами:
На, кушай https://metanit.com/sharp/
> а что-то вдруг начало бешено крутиться на обычно спящем ядре... после билда C#.
У таких систем (не только в шарпах) бывают всякие сторонние штуки запускаются для последующей оптимизации/кэширования. Особенно если это разработка (debug mode).
Я даже видел какой-то отдельный процесс, который чуть ли не буквально назывался "оптимизация шарпов/дотнета" (точно не вспомню).
Потом становится все шустро и нормально. как секс в первый раз
>C# показался чуть-чуть более доступным для теста...
Помни только условно паттерн:
много вычислении С# -> минимальный (желательно один) вызов из шарпов в GDScript
Если будешь в цикле дергать часто С# профита не будет.
Никакого маршалинга GDExt, только надо будет изучить сорцы годота. Вы годоты дети?? ДА КАПИТАН
>Скомпилировать.
Да скомпилировать-то легко - поставил всё нужное по документации и всё само компилируется. А как код писать? Сначала нужно разобраться, как вообще модули интегрируются в движок, чтобы не выдумывать какие-то костыли, которые отвалятся при апгрейде на следующую стабильную версию (C++ модуль, по идее, должно быть относительно несложно апгрейдить). Потом нужно разобраться в том, какое там API доступно и как его вызывать - оно адаптировано в первую очередь под работу через редактор со стороны GDScript же, а со стороны C++ что-то непонятное. Потом нужно будет не просто какой-то код писать, а писать и потом компилировать, запускать движок и тестировать, а C++ не отличается скоростью сборки и лёгкостью дебага. Если где-то начнётся утечка памяти, ты это можешь и не заметить даже, если не обложишься внешними профайлерами. И т.д.
Плюсы от такой разработки всё же есть: глубоко разберёшься в нюансах исходников движка и сможешь его подстраивать под себя или патчить критичные для тебя баги раньше мейнтейнеров; можешь прикрутить к движку что угодно легче, чем тем, кто знает движок только по GDScript; можешь собственноручно портировать игру с движком на какую-то нестандартную платформу, и т.п.
Но всё это весьма специфические вещи, нужные малому проценту геймдевов. И кому нужно - те уже этим занимаются, а кому не нужно - знать про такую возможность в принципе не обязательно. Вот когда задумаются "а как что-то прикрутить", тогда и узнают, что можно написать свой модуль, а пока пусть играют в "песочнице" GDScript и радуются жизни.
Так я привел пруфы, но из-за парадокса Блаба ты их не понял. (Если ты не знаешь какую-то тему, то рассказ о ней для тебя звучит как белый шум)
Кстати, уже вроде когда-то упоминали:
http://jenova-framework.github.io/
Кто-нибудь успел попользоваться?
Жаль, что билд старый - 4.7...
Я английский достаточно знаю, чтобы айти статьи в оригинале понимать.
>Если будешь в цикле дергать часто С# профита не будет.
Это очевидно. Я вообще рассматривал C# в основном из-за потенциальной возможности подтянуть ONNX без лишних костылей и прослоек - очень жаль, что нельзя подтянуть его или что-то похожее прям в GDScript, тогда C# мог бы и вовсе не потребоваться. Но этот ONNX оставлю на крайний случай, если собственный велосипед на квадратных колёсах не поедет.
А до этого хочется поэкспериментировать с кодом, в котором будет не просто много элементов, а много if/else развилок и неизвестных заранее прыжков по RAM (в чём CPU до сих пор превосходят GPU), которые в GDScript начинают проседать после всего нескольких десятков тысяч элементов, что очень печально... Я подумывал, что мне лучше всего подойдёт чистый C без классов, но туториалы в документации Godot как-то слишком сложными показались, и для базовых тестов сойдёт и того, что предоставляет C#, наверное. Просто не буду обмазываться классами и не будет лишнего оверхеда... так ведь?
Может даже многопоточность пощупаю, алгоритм легко параллелится...
>подтянуть ONNX без лишних костылей и прослоек - очень жаль, что нельзя подтянуть его или что-то похожее прям в GDScript, тогда C# мог бы и вовсе не потребоваться. Но этот ONNX оставлю на крайний случай, если собственный велосипед на квадратных колёсах не поедет.
Ты можешь написать gdxextension модуль, с которым gds будет общаться напрямую.
>Я английский достаточно знаю, чтобы айти статьи в оригинале понимать.
Хз что там за маны, но надо разделять новичковые мануалы и мануалы для тех кто уже в разработке что-то понимает (и порой просто хочется пробежаться по базовому синтаксису и принципам).
>подойдёт чистый C без классов
Да не нужен тебе С/С++, тебе нужно понимание алгоритмов и структур данных (100500 книг есть на эту тему). Вся суть разработки (прям вот реально вся) - это подобрать какой алгоритм/структура данных подходит для той или иной задачи - больше никаких секретов нет (я даже больше скажу, в 90% случаях тебе нужны будут только list и hashmap ну и надо понять что это не тоже самое что в GDScript, особенно списки).
Я не читал, но тут вроде немного воды.
https://metanit.com/sharp/algoritm/
Главное помнить про пик
Тот пример где переписывается List<int>, почему нет мусора в памяти, работает это так (с value type):
[] - буквально ячейки в памяти размером в тип
[8][3][2]
v[1] = 5
[8][5][2]
Мы просто затираем старую ячейку памяти.
А вот если был бы ссылочный тип
[ptr][ptr][ptr]
v[1] = new MyClass()
[ptr][new_ptr][ptr]
То тут да, мы переписали только адрес на объект, поэтому старый объект остался в памяти (и больше недосягаем вообще - утечка памяти для С++, или работа для GC).
То есть, можно в сложных местах сделать на структурах и будет подобие ECS.
Список структур залетит весь на кэш проца
struct Point
{
....public int X;
....public int Y;
}
[Point][Point][Point]
В памяти ячейка будет иметь размер двух int и возможно мета информация (плюс там еще может быть выравнивании памяти для скорости).
Главное чтобы внутри тоже был value type. Иначе процу придется бегать по памяти.
Но это прям ультра хардкор код в 100К-1КК итераций
>Про идею объединить GDScript + C#
Я думал над своей симуляцией и чтобы получилось эффективно мне пришлось мысленное почти всю симуляцию поместить в C#. То есть, я тоже думал разграничит GDScript + C#_спискодробилки. И иногда это получается, а иногда не очень (приходиться уже большие данные прокидывать между собой). В общем, как-будто проще все на С#. Но это мой случай, все еще можно написать отдельно какие-то системы (и судя по тестам GDScript, если упираешься в кадр, это нужно делать).
>А до этого хочется поэкспериментировать с кодом, в котором будет не просто много элементов, а много if/else развилок и неизвестных заранее прыжков
В мире шарпов про накладные расходы базовых операция (вызова функций, if/else итд) можешь забыть. Смело делай любые сложные системы. Все тормоза будут на аллокациях/сборке объектов и кривых алгоритмо-дробилках.
Но опять же, не надо переживать за GC, если прям в гиго цикле не насрёшь, то ты его не заметишь (плюс там еще поколения и прочее), ну еще мы часто подписываемся на RefCounted - это как раз годотовский подсчет ссылок (насколько я понял, годот забирает управление у шарпов).
>(насколько я понял, годот забирает управление у шарпов).
А нет, я наврал. Точнее нейронка мне назвездела, а я не проверил.
>Да не нужен тебе С/С++, тебе нужно понимание алгоритмов и структур данных
Перечитывай >>1106548
В сухих тестах при одинаково нормальных руках - С++ будет быстрее, но так софт не пишется.
Если брать замеры реального софта, где есть свои драмы, но по крайней мере это не замеры коня в вакууме (то есть реальный сетевой софт). То разница настолько мала, что использовать С++ в прикладном софте просто бессмысленно (по цене и усилиям).
А иногда бывает, что С# может работать быстрее из-за особенностей работы с памятью.
Простыми словами - ты натрахаешься больше чем получишь профита. Но если очень хочется - то почему нет, не самая плохая инвестиция времени для геймдева.
> Когда говорят O(N), это скоращение от t = O(N)•C, то есть нпдо домножить на время одной операции.
Когда говорят о сложности говорят в рамках одного языка и что C - неизменна (код один и тот же в итерациях), поэтому её опускают.
Современный .NET JIT активно оптимизирует код: инлайнинг, devirtualization, bounds-check elimination, PGO, SIMD и т. д. Microsoft, например, отдельно отмечает динамический PGO и машинно-зависимую генерацию инструкций JIT; Native AOT использует тот же JIT-компиляторный стек для генерации машинного кода.
Я думаю разница List<> и std::vector<> будет на уровне погрешности замеров (нефига).
У нас вся игра это сплошной кэш (in-memory cache) и списки. Где мы там хотим победить C# я не понимаю
> А как код писать?
Писать код на гдскрипте, затем: "робот, переведи вот этот файл в модуль годота на с++ и сгенерируй файл конфига для включения в сборку".
>Пи1
Я бы только поспорил с AGI разумом не уничтожайте меня
Шарпы скорее всего выделают себе "свою кучу" и потом уже самостоятельно гадят в свой хип, то есть никаких системных вызовов типа malloc не происходит (но это не точно). А значит создание объектов очень быстры
>Пик2
У джавы видно, ты дергаешь память и она растит свой хип. И поэтому кажется что джава сожрала всю память, но на деле это просто резерв. Го вообще очень часто старается отдать это "буффер" обратно операционке.
>Пик3
У шапрпов примерно так же. А еще узнал у шарпов 3 поколения, а не 2.
Когда уже норм движок на нормальном системном япе
На расте
Беви слишком медленно развивается, сука
А сам я его развивать и дописывать не буду
Я не умею, а нейронка дорого
Так уж получилось, что годотред постоянно либо над, либо под тредом движкосрача
>ржавый, блеви, баран-чеккер.
Люди игры хотят делать, а не жопу наждачкой вытирать
Так я и говорю, нахуй надо дописывать сырое двигло
Пусть авторы сами
А я приду на все готовое
>понимание алгоритмов и структур данных
Ты по упоминанию ONNX не догадался, что речь про нейронки? Вкратце: у ставших сегодня стандартными глубоких feed forward сетей главная операция - это перемножение двух матриц и затем суммирование отдельных колонок, что лучше всего ускоряется на специальных "тезорных" ядрах NPU или GPU, а для обыкновенного CPU это очень тяжело независимо от выкрутасов с кэшем, потому что двадцать гигов этих матриц в кэш не запихнёшь и тензорное ядро делает буквально тысячи операций умножения за 1 такт, а процессору нужны тысячи тактов для того же...
Но есть нюанс: перемножение матриц на тензорах выигрывает только пока матрицы плотно забиты значащими числами. Если твоя матрица на 99.99% из бессмысленного шума/нулей, то ты просто тратишь возможности устройства впустую. Нейронки сейчас оптимизируются специально под GPU/NPU, и любое расхождение с устройством тензора отрицается, что затормаживает развитие интересных альтернатив.
В общем-то уже давно есть библиотеки для особых прореженных (sparse) нейронок, но это всё изучать необходимо, а мне лень, я лучше велосипед сделаю. Вообще-то, сделал уже давно, на GDScript, и как-то разочаровался и забил. Год назад поставил .NET 10 и отвлекся на что-то, только сейчас вспомнил.
Идея в том, что у тебя гигабайты самых обычных искусственных нейронов в RAM или даже на SSD, но активируются что-то типа 1% от этой массы, как в современных MoE LLM, но чуть иначе. В MoE LLM все активации оптимизированы под тензоры, и так, чтоб обязательно были сплошные слои, не разреженные, поскольку по-другому тензорные ядра не умеют.
А CPU нет разницы, с какой частью RAM работать...
>нет разницы, с какой частью RAM работать
А, я имею в виду, что ядра CPU могут работать 100% независимо с разными участками памяти, а ядра GPU фактически обязаны работать с одним и тем же без возможности развилки, потому что если есть хоть 1 условное выражение - часть ядер просто вырубается, дожидаясь другую часть. И объём VRAM по сути без разницы, т.к. ядра не имеют прямого доступа, а "что положили - с тем и работаем", типа как принтер. Это наследство работы с графикой на экране, вроде бы.
Т.е. это "можно/нельзя", а не "быстро/медленно".
Ну и типа, вариантов не остаётся...
Не сильно понял. Используй ИИ как помощника, а не замену самому себе. Это решение будет всегда качественней.
Не знаю о чем ты, но если возвращаться к римке. То симуляцию гниение лучше сделать на велью типах.
То есть, быстро пробежаться по листу со структурами и сделать нечто:
for (int i; i < data.Count(); i++) {
var item = data;
if item.isRot()
item.rotting += 1; // мы чуток экономим на целых числах, хотя удобнее +0,01 делать
}
Это будет за кэш процессора, даже 10К-100К элементов (а может и больше, смотря насколько жирная структура)
Главное каждый кадр не делать (привет римворлд)
>Это будет за кэш процессора, даже 10К-100К элементов
Это не совсем верное утверждение, но все равно это быстрее чем ссылочные. Хотя GC тоже может как-то укладывать объекты.
Поработав с любым движком, получив базу тебе становится легче работать с любым другим движком (быстрее и проще вкатишься).
Поэтому первый движок как девственная плева - сначала больно с любым, а потом уже нормально со всеми.
Подскажите пожалуйста литературу или уроки по годоту?
Или движок интуитивно понятный и можно вкатиться через официальную документацию?
Заранее благодарю
По документации лучше да.
У годота ещё есть свой мини онлайн курс для совсем новичков, тоже можно пройти.
А так, лично я смотрел старый гайд по созданию экшн рпг, где чел впринципе всё что нужно для жизни разжевал
Там в шапке (по ссылке) были какие-то книги. Устарели наверное ещё в прошлую эру Септима.
Лист под капотом имеет си-лайк массив - упорядоченную память (не путать с ассоциативными массивами в динамических языках).
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/arrays
То что список ссылочный тип это пофиг, главное что итерируется значимый тип (я не помню как в переводе называют)
Ну не знаю, там получается под капотом Olog(n) а ты на собесе показываешь красивое On А всё потому что наружу выставлен сахар на сахаре, а погонка указателей по куче упрятана под капот.
Там JIT схлопнет цикл. Не будет там на каждый элемент поиска заново, сейчас не 2000 год.
Да, я там ошибся, там приходиться структуру создавать (хз почему это нельзя оптимизировать).
Но вся разница между базовым массивом и списком именно в создание структуры
Я хз как этот момент оптимизировать - AsSpan не сильно помог.
Объект с велью типами отработал как структура (там +-0.030 погрешность)
Ссылочные операции тоже не сильно проседают в тех масштабах, безумия если только начинаем аллоцировать в цикле.
Так что структура это в первую очередь про аллокацию и мусор. Если объем статичен лучше базовые массивы юзать.
https://pastebin.com/JwvB6U4C
Надо бы это еще на новой машине запустить. Может на некропеке нет каких-то иснтрукций.
Не очень разница, но какой легкий класс с велью типами.
Как вы сидите в этой черной дефолтной жопе
На самом деле надо найти либу или написать свою. Потому что слишком чувствительные погрешности в таких масштабах (при одноразовом прогоне). Среднее значение прыгает как третьекурсница по комнатам в общаге.
Но так, на глазок норм.
>на новой машине запустить
Которой 6 лет, лол.
Но вообще наглядно если, если делать игры-симуляции где у тебя список погоняет списком и делать под некропеки (как я хочу) то прям шарпы норм так заходят, разница меньше чем х2.
Ну че почаны, римвордл с 100 поселенцами?
Я хотел zig, автор фанатеет от выравнивание байтов
https://www.youtube.com/watch?v=IroPQ150F6c
То есть, для симуляции нужен по-любому ECS и даже какой-то свой аллокатор который бы все компактно делал. А это месяцы изучения и исследований (ждем когда напишут).
Найти бы еще такую симуляцию, которую интересно было бы играть больше чем 15 минут (собственно, почему я в годоте прототипы и делаю).
>легче делать прототипы
>движок из коробки поддерживает 10% форматов ассетов от тех что поддерживают другие игроки рынка, хотя казалось бы - опенсорс, ан нет, ищи конвертеры.
>ВСЕ ЕЩЕ НЕРАБОЧИЙ МАГАЗИН АССЕТОВ, благо что есть нейронки которые могут переводить юнити ассеты в годот, но это не заслуга движка ни разу.
Движок-прототип для игр-прототипов
Это чудик, у которого прототипировать = скачать десять тысяч моделек, засунуть все сразу и удивляться, что тормозит и не может найти их в папках.
чел зачем-то воссоздает мортал комбаты с пс2 на годоте, уже играбельно:
https://gatitomimoso00.itch.io/mortal-kombat-3d-era-remaster
>Не сильно понял. Используй ИИ как помощника, а не замену самому себе. Это решение будет всегда качественней.
Ты вообще ничего не понял...
>>1107559
>если возвращаться к римке. То симуляцию...
Представь себе, что у тебя "римка", только NPC один единственный и взаимодействует не с симуляцией, а с реальностью, через устройства ввода-вывода, в т.ч. механические манипуляторы. Вот это игра века. А с тупейшими болванчиками как-то слишком скучно.
>>1107693
>Найти бы еще такую симуляцию, которую интересно было бы играть больше чем 15 минут
Твоя проблема в том, что ты "ищешь симуляцию", а не придумываешь правила. Чтоб симуляция была очень интересной, нужно либо очень много правил, которые взаимодействуют друг с другом, либо способность к эмерджентности как у игры "Жизнь" Конвея, где всего парочка правил дают мощь симулировать что угодно.
>поддерживает 10% форматов ассетов
Лол, а тебе нужно ковыряться в говне мамонта, что поддерживался 1 проприетарным разрабом в 90-х и благополучно вытеснен открытыми стандартами?
>ищи конвертеры
Любой опенсурс редактор графики/звука/видео поддерживает множество форматов, включая те, о которых ты ничего не слышал и вряд ли увидишь. Конкретно игровому движку нет необходимости реализовывать всё это старьё в базовой версии.
>НЕРАБОЧИЙ МАГАЗИН АССЕТОВ
Тебе так не терпится ПОКУПАТЬ ассеты? Из реально полезных ассетов разве что Terrain3D и Godot Voxel. Остальное тебе для прототипа вообще не нужно. Да и большинству инди-игр даже террейн не требуется, достаточно вылепить что-то в Blender или чисто из примитивов CSG прямо в Godot собрать.
>>1107596
>Или движок интуитивно понятный и можно вкатиться через официальную документацию?
Да, лучше читать официальную документацию, всё необходимое для старта там есть.
>>1107562
>Стоит юзать Годо для 3Д веб-игрушек на мобилку, чтобы сэкономить время, не изучая нормальные веб-движки Триии.жс и Вавилон.жс?
Стоит хотя бы попробовать. Какой у тебя опыт? Зачем обязательно веб, а не нативный apk, если ты сам себе игрушку делаешь, а не для публикации где-то? Есть конкретная идея или хочешь экспериментировать? Возможно слепить задумку на Godot по-быстрому, а в последствии переписать на более оптимальное - с уже продуманными и оттестированными механиками, без необходимости делать кучу перезапусков и правок.
>мобилка не самая мощная
Могут быть проблемы; как минимум будет греться. По личному опыту скажу - Godot не может работать без нагрева телефона, как минимум в формате apk, и я не понимаю, с чем это может быть связано, т.к. я видел игрушки, которые вообще телефон не нагревают.
>насколько то что я вижу в превью редактора будет соответствовать готовой страничке после экспорта?
Зависит от версии браузера и библиотек Android, что поставляются разработчиком смартфона в момент создания модели смартфона и не обновляются. Тут проблема в зоопарке видеочипов и браузеров, что в приниципе сложно подружить друг с другом. Просто старайся не использовать технически сложные фичи наподобие динамических теней и декалей, сложных шейдеров и т.д. Но меня как-то особо не привлекала разработка для игры в браузере, так что я почти не тестировал, и не знаю про актуальные проблемы...
Я в прошлые годы накачал тысячу моделек. (Сейчас это бесполезно, потому что все завалено или бессмысленными необработанными сканами, или нейрокалом).
И большинство случаев покрывал gltf/glb. На скетчфабе там автоконвертация, если в браузере показывается, то скорее всего с моделькой все в порядке было.
Если автор выложил только в fbx, то тоже все просто, конвертер для этого давно придуман и называется блендер. Его все равно приспособили в пайплайне для склеивания миксамо анимаций, которые качаются в виде fbx.
USD, вроде как, особо не распространен пока, ну для него аддон где-то видел уже.
Отдельная история с анимешками в VRM, ну там опять же свои специфичные фичи, есть аддон от VSekai, уж не знаю что он пилит за игры, но дорабатывает постоянно.
Один раз за все время столкнулся с моделькой из 3дмакса, ебался полдня с конвертерами, в результате оказалось что моделька говно и пользоваться ей все равно нет смысла. В мусорку.
В общем, ничего удивительного, опенсорсные форматы поддерживаются, навороченные опенсорсные поддерживаются энтузиастами в аддонах, проприетарные компании надрачивают друг другу и поэтому конечно готовые добавлять всякие закрытые форматы, а опенсорсные реализации не давать.
>Твоя проблема в том, что ты "ищешь симуляцию", а не придумываешь правила.
В этом и смысл. Правила придумать и скопировать просто, но за этим стоит тонна рутиной работы по заполнению контента (или выйдет поверхностная игра, я уже это проходил ни раз).
Почему программистов цепляет римка и подобное - потому что за этим минимум визуала и больше симуляций.
Плюс сама симуляция может порождать правила и контент. В той же римке, пока не сломали в 1.6 (или в 1.5, не помню) - был лучший бесконечный антагонист в игре. Бесконечный в плане, что долго не приедался. Теперь, когда его сломали - стало понятно что его сделали случайно. То есть, у автора была идея сделать генератор истории и случайно он уловил тонкую грань, но не стал анализировать и просрал (но в масштабах игры это уже и не важно).
Что это говорит - что можно сделать интересные симуляции, но это тоже тонкий момент. Причем в такую игру ты и сам реально сможешь играть периодично и это не будет притянуто за уши (обычно к таким играм возвращаются раз полгода/год).
Как же ты задолбал со своей "римкой", хотя сам же утверждаешь, что играешь в неё раз в год неделю... Серьёзно, примитивная игрушка (если без модов), насколько нужно быть фанбоем, чтобы так часто упоминать про "симуляции" в ней? Почему не DF?
>Правила придумать и скопировать просто
Если это так просто, почему ещё не сделал?
>тонна рутиной работы по заполнению контента
1. Открываешь https://conwaylife.com/ и играешь.
2. Делаешь на Godot за один час ручного кодинга.
Считай, это важнейшая симуляция из симуляций.
Дальше: https://en.wikipedia.org/wiki/Artificial_life
Просто открывай все ссылки, читай, изучай...
А на "римку" забей - это фейк, а не симуляция. Те же нападения генерируются случайно, т.е. они никак не существуют до того, как свалятся тебе на голову. И отношения людей также спонтанно происходят. Т.е. симуляцией тут и не пахнет, скорее "декорация"...
>Дальше: https://en.wikipedia.org/wiki/Artificial_life
Пипец, стоит на минуту отойти - статью портят шизы.
https://en.wikipedia.org/w/index.php?title=Artificial_life&oldid=1367090335
- более-менее живая версия статьи как я её помню.
Или: https://ru.wikipedia.org/wiki/Искусственная_жизнь
>Как же ты задолбал со своей "римкой", хотя сам же утверждаешь, что играешь в неё раз в год неделю...
>>обычно к таким играм возвращаются раз полгода/год
Где сказано что я играю в неё. У вас школьников черно белое мышление, если я говорю что в игру возвращаются через полгода, значит что есть такое явление/наблюдение.
Я не могу сделать бесконечную игру, но я могу сделать реиграбельную, на это стоит обращать внимание.
>Серьёзно, примитивная игрушка
Это заявление о профнепригодности как геймдизайнера.
Говорить что популярна игра "ряяя говно" - признак малолетки с /vg
Но да, римка правда переоценена, но это лишь значит что надо понять почему (я знаю и говорил).
>Почему не DF?
Был бы моим поклонником знал что я часто упоминаю DF как более качественную версию, а еще song of syx (и еще какие-то, я уже не помню, я анализировал рынок 10 месяцев назад). Просто это имя нарицательное. Когда я скажу рим-лайк или скайрим-лайк ты сразу поймешь о чем я (скорее всего нет, ты же подросток без критического мышления, ты при фразе скайрим-подобная игра, представишь именно скайрим, а не какую-то его возможную множественную вариацию - это сложно для подросткового мозга).
>Игра жизнь
Игра без игрока - интересная "игра". Думаешь сложно сделать подобие муравейника с рандомайзером? Делал и не раз. Даже делал цепочку производств частично похожую из факторио (не конвейер, а на дронах). Но когда юниты делают все сами, тебе еще скучнее. Если оставляешь постройку на игрока, то тупо сидишь на 10х скорости ждешь когда они там кирпичи доплавят и построят (чаще тупо перегружаешь их).
Собственно в римке ты практически тоже ограничен постройкой. Поэтому там есть этот бесячий микроменджмент. И что выходит, когда ты из /vg - ты думаешь что это плохой геймдизайн. Но когда ты становишься /gd - и воспроизводишь это - ты понимаешь что это наоборот тонкости реального геймдизайна, иначе игра сразу коллапсирует в кактус.
Ну еще сами рейды - это тоже оттягивание постройки и элемент выживания.
Вот чем должен отличаться игрок от индюшника и именно это и нужно в /gd обсуждать - все эти тонкости геймдизайна.
>Те же нападения генерируются случайно, т.е. они никак не существуют до того
А вампирике или тавер-дефенс тебя это волновало?
В общем, ты нефига не понимаешь, но громко рякаешь забайтил на длиннопост, лалка
>>Те же нападения генерируются случайно, т.е. они никак не существуют до того
Кстати, в моем дизайне было поведение как в факторио - если загрязнение доходит до жуков - они начинают нападать. Если такого нет, то проблемы не будет, но жуки могут тайно мигрировать и строит базы в близи. И чтобы обнаруживать такие точки была работа (task/job) разведчика (просто пешка должна уйти за карту и появиться в стратегической карте).
Пикчи как всегда
>Где сказано что я играю в неё.
САМ В ИГРУ ДАЖЕ НЕ ИГРАЛ
@
ПОСТОЯННО ЕЁ УПОМИНАЕТ
>Я не могу сделать бесконечную игру
Бесконечная игра - игра без Game Over. В чём проблема?
>но я могу сделать реиграбельную
Реиграбельность субъективна. Кто-то и визуальную новеллу будет перечитывать каждый месяц по традиции - это считать реиграбельностью? А если кто-то поиграл в условную Dota 2 пару часов, блеванул и больше не трогал - это считать как отсутствие реиграбельности? Так что ты просто неправильно понимаешь то, почему игроки возвращаются в игру. Нужно не "реиграбельность" повышать, а напрямую стимулировать возврат игрока. Например: ежедневные задания с бонусами каждый день, какие-то временные/сезонные события, всякие еженедельные бонусы/смена правил, сундучки с ништяками, сбор ограниченных ресурсов, которые восполняются только в реальном времени и нужны в большом масштабе, механики idle - когда за время оффлайна даётся бонус при возврате, и так далее. Вот это настоящая "реиграбельность", ради которой игроки сливают тысячи часов в одну игру, а не какие-то тупые болванчики, принимающие случайные решения в случайных ситуациях и дохнущие в силовой броне от одного тычка палки голозадого бомжа, полностью забив на симуляторность...
>Это заявление о профнепригодности как геймдизайнера.
А что ты скажешь на то, что Oxygen Not Included намного более сложный симулятор и при этом более честный к игроку, хотя и имеет меньшую аудиторию? Очевидно же, что успех/популярность игры скрывается не только в геймдизайне, но и в маркетинге (в том числе через стримы, соцсети и т.п.), а также в моддабельности игры. Я не знаю, есть ли порномоды на ONI, но даже если есть, про них не говорят на каждом углу так открыто, как про порномоды RimWorld, что должно открывать тебе глаза на то, кто является целевой аудиторией RimWorld на самом деле (кумеры, дрочащие на насилие и разврат). Так что ты не там ищешь причину успеха и не на тех геймдизайнеров ориентируешься, если хочешь сложную игру.
>скайрим-подобная игра
Ну, это вообще шиза какая-то. Предыдущие две игры были сложнее и качественнее, просто Skyrim был более продвинутой графикой и поэтому получил наибольшее число модов. А так, если бы Skyrim вышел на десяток лет раньше, про него бы забыли и не вспоминали, как и про все остальные древние 3D RPG, известные только коллекционерам. И если уж на то пошло, "Skyrim-like" - это что-то вроде "GTA-like, только в средневековье с магией и лошадьми", потому что именно GTA-like назывались все опенворлд игры со свободой действий игрока и нелинейным выбором квестов на огромной карте. Как-то отдельно выделять "Skyrim-like" из мета-жанра "GTA-like" это как отделять фэнтези от научной фантастики, когда речь идёт о фантастике в общем и целом или о художественной литературе в общем и целом... Избыточно.
>Игра без игрока - интересная "игра".
Почему в кавычках? Игра без игрока - это буквально жанр "Zero Player Game", ZPG. Как RPG, но ZPG. И таких игр было уже выпущено очень много. Кстати, жанр idle/clicker соприкасается с ZPG и может в целом относиться к нему как подвид - а мы все знаем, что люди обожают idle/clicker и играют в них больше, чем в "нормальные" игры. Т.е. ZPG в целом - топ жанр. А если тебе не нравится, что ZPG называются играми - то они намного больше игры, чем, скажем, визуальные новеллы и прочие квесты, потому что у ZPG хотя бы есть какая-то симуляция состояния мира, а не просто слайдшоу с надписями.
>Но когда юниты делают все сами, тебе еще скучнее.
Просто признай (для самого себя, не для меня), что ты ненавидишь жанр симуляторов и пытаешься сделать в нём что-то только из-за того, что боишься учиться рисовать всерьёз или не хочешь прибегать к генеративным нейронкам. Какой смысл грызть этот кактус, если он тебе никогда не нравился? Не нравится - не лезь, не играй, не делай эти игры. Это не для тебя.
>Собственно в римке ты практически тоже ограничен постройкой.
При том абсолютно тупой и скучной по сравнению с конкурентами.
>ты думаешь что это плохой геймдизайн
И правильно думаешь, ведь
>иначе игра сразу коллапсирует в кактус
- другими словами, Тянан тужился-тужился, тужился-тужился, но так и НИАСИЛИЛ придумать интересный геймплей, поэтому он по максимуму растянул все активности и навернул побольше "СМЕРТЬ ЭТО ВЕСЕЛО", чтобы тупые хомячки, клюнувшие на весёлые стримы игры, не успели просечь примитивность игры за 2 часа после покупки и вернуть деньги. А потом "модами допилят" и попытки оправдать неудачные действия автора, чтобы сгладить боль от своей ошибочной покупки.
Понимаешь,
>все эти тонкости геймдизайна
- это на самом деле костыли и заплатки на дырявом корыте, а не хорошая работа. Хорошая работа - это когда ты рассчитываешь поведение мобов так, чтобы они давали игроку достаточное испытание и достаточные переживания, но не нагибали его с первого удара, а отдавались ему, но и чтобы отдавались не с первого удара. Скажем, когда босс замахивается на игрока и даёт ему две секунды на нажатие кнопки прыжка - это хорошая работа. Когда моб прикрывается щитом и игроку приходится думать головой, чтобы пробить этот щит или обойти его - это хорошая работа. А когда твои мобы спавнятся у игрока на базе, начинают всё крушить вокруг себя и взрывать припасы - это грубая затычка для искусственного затягивания и без того медленного и скучного геймплея. Когда герои игрока в силовой броне теряют конечности и умирают от тычка палкой бомжа - это грубая затычка для всё того же затягивания геймплея, а не "генератор историй". Т.е. вместо проработки противников и балансирования ты берёшь и делаешь так, чтобы игрок проигрывал в самых абсурдных ситуациях, не считаясь с чувствами игрока - а чтобы он не бросил игру, вешаешь лапшу на уши про "генератор историй". Это издевательство над игроками должно быть запрещено похлеще всяких лутбоксов, не считаешь? Буквально обман как он есть, в самом худшем его виде. Все игры строятся на уловках и хитростях, но тут просто обман.
>А вампирике или тавер-дефенс тебя это волновало?
Эти игры не заявляются как "симуляторы" в большинстве случаев. В буллет хевене ты изначально знаешь, что все мобы - это лишь точки на экране, появляющиеся случайно и только с целью умереть об тебя. В тавер-дефенсе ты знаешь, что эти точки появляются только чтобы пройти по обозначенной линии и умереть об твои башни. Это честно, пока автор или фанат игры не начинает бросать заявления о "симуляции жизни" и наворачивать всякую ненужную, декоративную хрень вроде отстрела конечности моба, и потом выставлять это как важную механику (типа ты не только башни строишь, но ещё должен прицеливаться в конечности).
А что с римворлдом? Ты вот тут его называешь "сИмУлЯтОрОм", его часто называют "симулятором колонии" (колоноскопии, скорее), автор сам называет "генератором историй" или что-то вроде того. А что получает игрок? Кучку дебилов, которые стремятся умереть поскорее от любой абсурдной причины, и генератор этих абсурдных причин, стремящийся прибить всех дебилов поскорее. При том известно, что игра активно наказывает игрока за рост колонии - чем больше оценка вещей в золоте, тем агрессивнее рейды, но ты не можешь сделать большую колонию из говна и палок, и поэтому ты ограничен кучкой дебилов тел в 10-20. Какая это колония? Максимум туристический лагерь, разбитый кучкой друзей в какой-то опасной зоне. Даже деревня в условном Stardew Valley и его предшественниках и последователях больше тянет на "симулятор колонии", чем вот это вот агрессивное говно, стремящееся всеми силами испортить игроку настроение. Хотя, как известно, среди игроков полно мазохистов (любители Dark Souls и т.п.), так что для кого-то именно такой геймплей - самый хороший и продуманный, наверное, но нужно сразу предупреждать об этом, типа "эта игра для тех, кто любит страдать и быть наказанным за то, чего он не делал", а не "симулятор колонии".
В упомянутой выше ONI хотя бы понятно, почему твои болванчики умирают - потому что ты не разобрался, как выживать, и в итоге, например, засрал всю атмосферу углекислым газом или заразил единственный источник чистой воды и т.п. То есть ты можешь проанализировать свои действия и стать лучше, развиваться. А в RimWorld ты будешь проигрывать просто по броску кубика игры. В этом и заключается разница между настоящей симуляцией (чёткие правила) и издевательством (декорации + рандом).
>Бесконечная игра
Это скорее возможность удержать вовлеченность игрока максимально долго.
Бесконечный размер мира не делает игру бесконечно интересной.
Достигается это разными стимулами и способами. Даже в доте, в соревновательной игре, где в теории не нужно завозить контент, приходиться менять цифры местами, создавать искусственно меты - в общем, делать максимально чтобы "глаз не замылился".
Внутри как-будто есть переключатель - "меня обманывают". И вот когда ты (бесознательное) видишь повторяющийся паттерн - ты теряешь интерес. Даже в доте есть ощущение "опять тоже самое, сколько можно".
Попробуй поиграть я.игры - там моментально наступает этот момент.
То есть - твоя задача как геймдизайнера - максимально спрятать цикличность через прогресс игры. А это тонна работы с контентом.
>А что ты скажешь на то, что Oxygen Not Included
Много раз пытался не то что поиграть, хотя бы стрим посмотреть.
Я понимаю что там тоже много идей, но у меня детская травма от вида с боку меня били приставкой денди по голове :)
Так же там антагонист сама система и симуляция. Мне больше по душе тавер-дефенс (рейды-отдых-рейды итд).
>Zero Player Game
У меня есть идея сетевой ZPG. Но мне будет трудно её делать, потому что именно мне такое не нравится (точнее скучно, нулевая вовлеченность).
>Просто признай (для самого себя, не для меня), что ты ненавидишь жанр симуляторов и пытаешься сделать в нём что-то только из-за того, что боишься учиться рисовать всерьёз или не хочешь прибегать к генеративным нейронкам.
Все остальные жанры - это рутинная работа. Как я писал - ты вынужден заполнять контентом, чтобы повысить вовлеченность. Да, художники кайфуют именно с этого, а у меня вечно кружок дерётся с треугольником. волк два месяца был прямоугольником
Поиск интересных систем (разного рода симуляций) это тоже фан.
>- другими словами, Тянан
О, я тоже могу часами его покрывать. По ощущениям римка стала римкой больше заслуга комьюнити, а то что она некачественная - это прям заслуга автора (и никто не играет как он задумывал - генератор историй). Но люди уже давно навернули модов сделав свою сборку.
to be continued
>Когда герои игрока в силовой броне теряют конечности и умирают от тычка палкой бомжа - это грубая затычка для всё того же затягивания геймплея, а не "генератор истории"
Ну генератор драмы же. Тупой, но генератор.
Да никто в ванилу не играет, там есть целые сборки с норм расчетом брони и прочего.
>А когда твои мобы спавнятся у игрока на базе, начинают всё крушить вокруг себя и взрывать припасы - это грубая затычка для искусственного затягивания
Тебе все равно нужен антагонист. Просто идея гения что защита базы это задача пешек - чтобы они умирали (генератор истории же). Там до сих пор борятся с килл-боксам, как ответ на тупой дизайн.
Но придумай лучшего антагониста? Загрязнение? Голод? Экономика? Это трудно балансить и трудно сделать долговременным.
Куда лучше поставить пулемётную точку - и тогда твоя мотивация уже приносить патроны. А патроны это добыча руды - плавка руды, добыча угля - в общем, чтобы повысить качество выживания нужна уже цепочка производств, тут и мотивация.
https://www.youtube.com/shorts/WxkTKeYYRZg
Забавно как игра в момент статуса агрессии посчитала всех жуков в одну точку. Как-будто был только один "дальний" поиск пути, а все остальные посчитались по этому ближнему жуку, но в момент близости все разбежались.
То есть, это прям какая-то оптимизация для дальненго маршрута. Считаем один путь, а когда близко считаем нормально.
Можно побыстрее скипнуть ненужное (C#).
>inb4 синдром утёнка
Он же написал - bitpacked array. Очевидно если тебе надо 4 бита, то можно в каждый байт 2 значения упаковать. Если 3 бита, там уже неудобно считать и сдвигать придется.
Скоро уже нейросети нам создадут биндинги паскаля в годот, чтобы на паскале игровую логику писать. Человеки, к сожалению, не стали это делать. На гитхабе валяются заброшенные пробы ещё под трёшку.
Я так понял это что-то вроде лодов для текстур.
Интересно, а у VRAM будет фрагментация памяти от такого? Предполагая, что когда ты отошел от города, текстуры домиков выгрузились, загрузились меньшие мипмапы, Компактизируются ли они или между ними будет много слотов под такие же маленькие текстурки
Люди пишут выравнивание структур чтобы процессор быстрее отрабатывал, потому что он оптимизирован под это. А ты хочешь в мир нестандартный данных погрузиться? Чтобы что?
Это дурка, ты делаешь то что не понимаешь, и делаешь это там где это катастрофически важно, а нейронка, которая заточена быть хорошим собеседником и подстраивается под тебя - галлюцинирует вместе с тобой.
У меня специальная кнопка продувки вентилятором.
Вообще ппц, с отключеным турбо, сайты хуже грузятся, проги глючат. Еще не пробовал ставить 45W/65W TDP. А вообще пишут термопасту менять надо, на этой серии говна.
Пикча не моя, но когда чистил ноут у меня там такая спрессованная "ткань" оказалась, она занимала нижнею половину радиатора.
В общем, хотя бы фонариком просвети, если ноуту овер-много-лет (и он разборный).
Если руки из жопы - то не лезь.
Как-то перезапекать в соседнем потоке или разрушаемые объекты делать через статичные NavigationObstacles (а их много их)?
Там же можно как-то почанково мелкие navigation region перезапекать, а не весь целиком.
Ты тиспо хочешь разрушаемый "пол"?
Нейронка тоже говорит про чанки и перезапекание.
>Ты тиспо хочешь разрушаемый "пол"?
Редко-разрушаемые стены/предметы в 2D, которые могут разрушаться от интенсивного огня или взрывов и создать проход.
видел готовую демку, там мост отключался, но что-то пока не могу найти. Но да, думаю или перезапекание или обстаклы.
>обстаклы
ИИшка говорит нельзя, что это больше про избегание и не про это.
Я думал есть специальные механизмы, а нету. Может как-то визуально делать обломки и запекать в соседнем потоке (если возможно). Но это никак не помогает при строительстве.
А у тебя разрушаемые стены всегда разные? Прост, если одинаковые то тогда намного проще
Ну тогда тебе не придётся перезапекать. Просто также запекаешь разрушенные места, но заранее, затем, когда надо включаешь их, так сказать в игру.
Опиши сначала свою игру - геймплей и графика.
Возможно, тебе вообще навигация не нужна...
>выравнивание структур чтобы процессор быстрее отрабатывал, потому что он оптимизирован
Оптимизация - это всегда жертва чем-то ради чего-то. Увеличивая скорость, ты уменьшаешь объём памяти, доступной тебе для размещения данных. Увеличивая доступную память, ты уменьшаешь скорость. Вопрос заключается в том, что тебе важнее - скорость или оперативка, доступная для работы твоей проги?
И вот разработчики C# приняли решение за тебя - они принуждают тебя к прожорливому потреблению RAM, поскольку у тебя нет инструментов экономии RAM. Ты вынужден жертвовать RAM ради ненужной скорости. Получается, что часть алгоритмов могут вообще не уместиться в доступную тебе RAM - вылетят в файл подкачки, на порядки ограничив твою скорость. Т.е. "оптимизация скорости" приводит к замедлению.
Конечно, можно ПРОСТО купить побольше RAM... Кабанчикам с их облачными серверами это легко. Обыкновенному потребителю - нет, тем более в 2026. Кризисная ситуация с RAM только набирает обороты.
>Тебе все равно нужен антагонист
>Но придумай лучшего антагониста?
Ты же сам пишешь, что >>1107845
>видишь повторяющийся паттерн - теряешь интерес
Чем тебе поможет "антагонист", если ты выучишь все паттерны и тебе моментально станет скучно?
Серьёзно, погугли побольше на тему реальной (типа научной) симуляции эволюции и живых организмов. Надоедают повторяющиеся паттерны? Эволюция автоматически генерирует новые паттерны, почти до бесконечности. Нужен антагонист? Большинство этих паттернов "умирают", потому что плохо подходят под конкретную задачу (выживания), и остаются лишь подходящие под условия среды индивидуумы. Если упрощать, то всё сводится к игре "Жизнь" Конвея, но необязательно делать клеточки на клетчатой карте: индивидуумы могут быть 2D и 3D, даже со сложными скелетами (хотя бы как в Spore), передвигаться прям физическим движком, а не прыжками по клеткам. И обладать собственными мозгами на нейронках...
Единственный подводный камень всего этого - до интересных результатов эволюция медленно идёт, и, возможно, изначальные условия среды слишком уж жестокие для твоего симулятора, так что придётся подгонять параметры и всё такое. Но ты не сможешь достичь чего-то интересного без помощи генератора, поскольку ты как создатель будешь знать паттерны до имплементации этих паттернов в движке игры.
Видео я не смотрел, но я приблизительно знаю, как происходит стандартный поиск пути в RimWorld. Там громадная карта делится на маленькие чанки; поиск происходит на двух уровнях - по чанкам и внутри них. Например, если NPC нужно пройти до клетке внутри отдельного чанка - он ищет путь внутри чанка. Если необходимо найти путь до клетки в другом чанке - он путешествует по чанкам, пока не дойдёт до нужного. Поскольку маршруты по чанкам одинаковые у NPC, стартующих из одного и того же чанка, они как бы "склеиваются" в одного и маршируют вместе, а уже в достигнутом чанке рассредоточиваются кто куда.
Так что да, это оптимизация, и она приводит к куче неприятных эффектов в процессе геймплея, т.к. NPC впустую делают лишние крюки или просто теряются, казалось бы, на очень простой местности. Вроде бы существует мод, направляющий навигацию...
>текстур стриминг версия годо уже попробовал?
Чтобы его попробовать и оценить качество, нужен 3D проект с большим количеством больших текстур, что занимают собой бОльше видеопамяти, чем доступно. Большинство инди/годотеров стараются делать так компактно, чтоб вся игра в памяти умещалась, или загружать ресурсы по уровням/чанкам вручную.
>>1107942
>а у VRAM будет фрагментация памяти от такого?
А почему тебя это заботит? Дефрагментация памяти, кажется, полностью лежит на ОС/драйверах, а для приложения нет возможности выбрать, где будут размещаться те или иные данные... Т.е. ты просто запрашиваешь у графического API участок памяти и используешь его, а не так, что движок сидит и ищет достаточно большой ряд ячеек в обход всех API.
Стриминг текстур - это не что-то новое, таким многие крупные игры страдают, потому что иначе они бы не умещались в памяти. GTA 5 Online с 50 Гб до 150 Гб дискового пространства раздулась, а по VRAM у неё фиксированный бюджет в ~1.5 Гб на минималках, соответственно, эту задачу до 2013 года решили...
Чел, тебе говорю что ты делаешь херню, мне твои виляния, копиум и маневры не нужны. Иди просто проверь эту информацию, мы тут не для того чтобы компенсировать чувство собственной важности, мы тут ради технической информации.
>Чем тебе поможет "антагонист", если ты выучишь все паттерны и тебе моментально станет скучно?
Вот вот мы уже близки к идеи, что нужен такой "антагонист" за которым игрок долгое время не увидит простоту и цикличность (что его обманывают).
>эволюции
>симулятора
У нас нет задачи сделать формальную модель мира. У нас наоборот весь мир это игрок. Задача зацепить игровые триггеры и продержать их максимально долго. Желательно потратив на это минимум усилий (потому что мы соло делаем).
Простая формула игры на миллион.
>>1108136
Это называется hierarchical pathfinding algorithm.
Забавно что никто не пробовал объединить NavMesh + AStar. Это надо тестить, но при больших пространствах это может быть эффективнее чем HPA
>Видео я не смотрел,
Зря
>поиск пути в RimWorld.
Он там написал свой какой-то HPA, идея вроде правильная, но иногда работает странно (это не проблема HPA это его проблема).
https://www.youtube.com/watch?v=RMBQn_sg7DA
Вспомнил в чем его проблема. Он дробит чанки на еще чанки (1). По началу кажется это лучше всего, но в реале это может приводить к безумию, когда в сложной конструкции у тебя чанки размером в пару тайлов или тайл. И вообще суть чанков это в их контролируемом масштабе.
В нормально HPA он вообще не должен этого делать (2).
Поиск по чанкам видит что доходит до нужной чанки, запускает там АStat и видит что цель недостижима. Он должен пометить переход как недостижимый и пойти дальше по чанкам (в верх или вниз).
Вроде так, я эту херню разбирал еще в январе, не помню.
Суть проблемы (1) - Астар очень эффективен в ограниченных пространствах, но в больших (очень больших), он ведет себя безумно (на карте римке может пройти 75% всех доступных тайлов).
В факторио видно (2) как должен работать HPA (но там тоже много вопросов как они считали переходы).
Пошли виляния сишорпера, у которого bool занимает 8 байт, а он причмокивает и просит ещё больше гениальных оптимизаций у Микровяленьких. Знаем вас таких, вы и хромиум сделали так, чтобы на компе у юзера никаких других приложений в памяти не оставалось, чтоб всё говно было доступно только через браузер. Но эпоха дешёвой RAM подошла к концу, не успев подарить всем пользователям хотя бы 256 гигов (литералли минимальная планка для актуального сервера, буквально бомжаций набор с помойки, ниже уже никак, пока у средненьких компаний по несколько терабайт опреативки в каждом блейде). Так что если делаешь оптимальное приложение, ориентируйся не на скорость, а на память.
>нужен такой "антагонист"
У всех игроков разные интересы в играх.
>У нас наоборот весь мир это игрок.
Но тогда ты вообще не занимаешься симуляциями...
>Простая формула игры на миллион.
Хватит грезить миллионами - в могилу их не заберёшь.
>объединить NavMesh + AStar
У NavMesh под капотом всегда используется AStar.
>Хватит грезить миллионами - в могилу их не заберёшь.
А чем грезить? Игрой которой никто не играет?
Миллион это приятный бонус, а не цель. Цель создать интересную игру.
Интересная штука. Несмотря на то что это выглядит стремно, треугольников все равно меньше в расчете, чем было бы с просчетом HPA.
Запекается гигабыстро даже без чанков (хз сколько в реале, я даже не чувствую).
Это будет очень быстро, только теперь никто не будет болота и прочие тайлы с массой учитывать.
Сишлоперу не нужно учитывать болота и прочие мирские вещи... Ведь у него СКОРОСТЬ!!!
Сишарп-господин пойдет и построит гибридную навигацию в зависимости от тайлов и комнат. А гдсрыг будет дергать либо сырое API, либо свой пинус.
Почувствуй разницу.
>гдсрыг
За такие слова в этом ИТТ треде принято пускать по массиву в триллион элементов. На GDScript, конечно.
Писать гадости про C# можно - это же корпоративная поделка, а корпораты - всегда антиутопичные злодеи.
Пока что пускали только гдсрыг. Причем по делу.сейчас бы осознано допускать чтобы годот окончательно вендерлочнулся на квази-язык
>а корпораты - всегда антиутопичные злодеи.
А что опенсорс не может иметь в себе успешных менеджеров, мотивация которых пилит себе фонд и выписывать премии? Там только могут быть добрые люди, а там только плохие?
Только вот существование кабанчика напрямую зависит от его продуктов, а существование фонда напрямую зависит от уровня хайпа.
>чтобы годот окончательно вендерлочнулся на квази-язык
Правильно, нахер этот C# вообще нужен с его ведролоком?
>>1108234
>менеджеров, мотивация которых пилит себе фонд
Это фигня, коррупция - не самое большое зло в этом всём.
>существование кабанчика напрямую зависит от его продуктов
Берём абстрактную корпорацию в вакууме, смотрим, чё они делают:
- лочат юзеров на свою подпиську/запчасти/веб-сервис, а потом кидают;
- монополизируются, выкупая конкурентов в зародыше и потом закрывая;
- используют абьюзивные тактики, внушая всем, что "это для вашего блага":
- отбирают свободы (лицензиями, судами и т.п.) у своих же потребителей;
- подкупают хомячков для улучшения восприятия своего бренда онлайн;
- кооперируются, делая монополию в обход антимонопольных законов;
- активно преследуют только собственную прибыль (в ущерб юзерам);
- милитаризируются, отделяются от государств(а), и так далее...
Опенсурс - это коллектив энтузиастов в первую очередь, а не корпорация.
>Это фигня, коррупция - не самое большое зло в этом всём.
Как раз это фатальное зло, потому что можно сделать минимальный жизнеспособный продукт и потом вкладываться только в маркетинг.
Раньше в технологиях (особенно в жабе) были такие люди как евангелисты (языка/техи) или сейчас называют адвокатами (языка/техи). Они не скрывались и это было нормально (кто-то тратит деньги на популяризацию - это норм). Но что-то где-то сломалось в период 2010-2015 года, попенсорс превратился в кормушку, а бренды в религию.
>Опенсурс - это коллектив энтузиастов в первую очередь, а не корпорация.
Крупный опенсорс это тоже самая корпорация. Попробуй что-то запулить в крупный проект.
Там давно челы на зарплате в фуллтайм работают. Вера что все вместе пишем софт - это инфантильная фигня, хз откуда.
>Правильно, нахер этот C# вообще нужен с его ведролоком?
Ты предлагаешь сразу делать на Zig?
https://www.youtube.com/watch?v=4CUGMRD3UwU
> Ты предлагаешь сразу делать на Zig?
Да, или на Rust или на С++, но ни в коем случае не на шарпах.
Тоже тестил эту демку. На моей iGPU выдаёт 10 фпс с просадками до 5 фпс, но - ВНИМАНИЕ - игра при этом необычайно играбельна. Считаю - лютый вин Godot, поскольку игры на других движках с 5-10 фпс обычно неиграбельны, а тут прям гладенькая годнота вышла.
Но при этом геймплей - унылое говно, сразу видно - художники делали: нарисовали красиво (условно), но геймплей и юзабилити (!) прямо скажем ублюдское... Например, герои часто теряются в темноте, и в них достаточно трудно кликнуть, как и в иные предметы. Противостояние с противниками выглядит как-то совершенно по-детски: "miss" - "miss" - "miss", и это в непосредственной близости, буквально дуло в живот упирается, а герой мажет 3 раза как полный идиот. И противник тоже. И стоим, мажем друг по другу. В чём заключается фан этой боёвки? Просто невыносимо. Собирательство лута на 99% состоит из 1 монетки и 1 сломанного замка, а с противников 1 батарейка и 1 непонятный кусочек мяса. И это когда по сюжету ты галопом бежишь к спасательным капсулам, лол.
Сюжет... или его начало - ну, норм, наверное. Озвучка забавная, но непонятно зачем она тут (лишние деньги некуда было девать?). Анимации прикольные, но вот перезарядка, блокирующая инпут игрока - маразм... Левелдизайн очень странный и бестолковый, как и перемещение камеры отдельно от игрока, т.к. можно натурально заблудиться камерой в декорациях. GUI запутанный и подсказки не везде, где нужно - зато накрутили аналог Википедии в диалогах, лол.
В целом, не для меня игра, так что даже не знаю, порекомендовал бы я или нет. Но жаловаться на производительность я бы не стал, т.к. это пошаговая игрушка с очень медленным, растянутым геймплеем, состоящим на 90% из диалогов и 10% унылейших, бессмысленных в своей пошаговости перестрелок. Наверное, единственный минус - это затраты энергии прожорливой GPU, но у меня-то маленькая встройка.
Алсо, компиляции шейдеров я не заметил. Молодцы.
Держите реакшон для форсов.
А, ещё момент: как же дико тупо выглядит дайс d20, анимируемый в некоторых ситуациях. Нафига? Они ролевичкам настольным так подлизывают? Не могу понять, чем кручение визуального дайса в GUI лучше стандартного для всех игр фонового рандома, что не отрывает от игрового процесса так, как этот дайс...
Алсо забавляет то, что эта игра собрала вокруг себя фанбойчиков из настольных ролёвок. От настолки тут буквально только этот дайс d20 и, видимо, сеттинг... В остальном это просто РПГшка японского типа (когда линейная сюжетка с конкретными героями в пати).
Короче, непонятный продукт. Если б не Godot, я бы не попытался даже бесплатную демку скачать. Зачем?..
>для форсов
Не форс, а мем!
Мнение коллеги?
https://gist.github.com/dalexeev/80ba4c4abda0637701a48095fb1604de
https://github.com/godotengine/godot-proposals/issues/14652
Дайс это уже что-то типа фансервиса. В БГ3 тоже был, заебало на него смотреть.
> и влепить анимированной текстурой?
Влепить куда? И на каких ресурсах будет обрабатываться эта текстура? В итоге, ответив на все вопросы, ты поймёшь, почему выбирают шейдер.
Логичным объяснением может быть то, что для высокого качества картинки, текстура должна быть достаточно высокого разрешения и в ней не должно быть заметных невооружённым глазом повторов (тайлинга). Ты же не можешь взять базовую текстуру песка размером 4096x4096 и налепить на неё эти блики из текстуры размером 16x16 пикселей - это будет выглядеть странно. Поэтому ты умножаешь затраты видеопамяти минимум в два, а то и больше раз, только ради одного этого эффекта. Поскольку в больших играх и без того приходится часто загружать-выгружать текстуры в VRAM и делить мир на чанки, в которых не более определённого количества уникальных материалов (иначе всё сразу не уместится в памяти), экономия памяти через процедурную генерацию эффекта может быть оправданной. Особенно если целевая платформа имеет достаточно вычислительной мощности и недостаточно видеопамяти для конкретной игры.
Но это касается ААА, а не ассетфлипов и поделок школьников. В ассетфлипах - что нашли, то и флипнули.
>>1108498 (OP)
>>1108498 (OP)
ПИЗДУЙТЕ
> биндинги паскаля в годот, чтобы на паскале игровую логику писать
Но...