Шапка: https://hipolink.me/godothread
Предыдущий 83: >>1104969 (OP)
---
Все статьи, читать: https://godotengine.org/blog/
Все версии, скачать: https://github.com/godotengine/godot-builds/releases
Я тут читаю учебник по Zig (в прошлом треде анон заинтересовал) и знаете что? Это же системный вариант гдскрипта! Тот самый, о котором мы мечтали не менее 40 тредов - вот же он!
Вы только поглядите на синтаксис. Мы же именно эти изменения.
Ну не знаю, кто куда, а я на зиг перекатываюсь. Вода замёрзла. Перебьёмся. Остаёмся.
Да, там автор написал какую-то построчную компиляцию, в итоге получается кодгенерить налету. В общем, системный язык но ведет себя как интерпретация динамикоязыков.
У этого есть минусы (и плюсы, конечно). Но в любом случае надо писать тесты на любых языках.
Надо еще понимать что это не язык для попила хайпа. И что это все еще односторонний интероп над сями.
Тот же пакетный менеджер ньюфагов точно отпугнет. Или ручная инъекция памяти/io. Да и не всем хочется обрабатывать out of memory при каждом добавление в динамический список.
В общем, если держать в голове что это "новый" си, то системный бойлерплейт терпим. Но тем кто кроме гдскрипта ничего не нюхал - будет сложно.
Еще им, вроде, удалось сделать асинхронный код без покраса. Но я еще не вникал, но звучит круто.
Zig очень хорош как язык, даже есть биндинги godot-zig, перекатывайся, я там был пару лет назад.
Вот это уже интересно. Изучаю дальше.
>>1108528
> кроме гдскрипта ничего не нюхал
Я нюхал от Паскаля с бейсиком до си, джавы, шарпа, питона, раста. Мне норм.
>>1108535
Мне нравится такой подход: на системном языке следует писать ядро игровой логики, со всеми менеджерами, фабриками, моделями, контроллерами. А на гдскрипте нужно писать логику подключения к этому ядру и настройки параметров.
В качестве системного я сначала рассматривал шарп, но оказалось, что он тащи за собой дотнет и нет простого способа сделать нативный билд. Потом я попробовал присмотреться к расту, но там меня разочаровала абстракция владения, которая должна была дать людям абсолютно непотопляемый код, надёжный как швейцарские часы, но люди не поняли и кодят на ансейфе. Кроме того ref<ref<ref<ref>>> окончательно добило интерес.
И тут такая Зига нарисовалась! Все нравится. Дошел до аллокаторов. Нравятся. Выглядят логично, понятно.
>Вот это уже интересно. Изучаю дальше.
Только учти что переписали они i/0 в каком-то последнем патче. Книги будут отставать.
>Вы только поглядите на синтаксис. Мы же именно эти изменения.
Какие "эти"?.. Загуглил хэлло ворлд, вы только посмотрите на это:
>const std = @import("std");
>pub fn main() void {
>_ std.log.info("Hello, World!", .{});
>}
Это же просто... просто... буээээ... простите... Это же C без ++!
Зачем все эти извращения? Чтобы что? Быть "не таким как все"?
Просто берите то, что удобнее - т.е. GDScript.
А для кранча больших циферок берите C/C++.
Что тут ещё можно выбирать 40+ тредов?
Алсо, завязывайте со скриптосрачем.
Это сорта прокрастинации у них. Ищут причины чтобы нихуя не делать, как всегда. Дай им супер-производительный годот-зиг-хуиг прямо в мейнлайне движка - найдут другую причину хуи пинать.
А реальность, напомню, на пике. И доля гдскрипта выросла относительно 2025 года.
Придётся более серьёзно изучить разные защиты проекта.
Забавно, но график больше показывает сколько вкатунцов любителей, залетевшие на хайпе и реальный разработчиков.
На гдскрипте не практично писать либы и любые системы/сервисы/менеджеры итд. Ну мы же не тетрисы делаем.
Ты думаешь, все прокрастинируют как ты, раз пишут в тред. Но ты не думал что реальность другая?
Ты еще не видел новый хелловорд с новым i/o.
И все равно это приятнее чем сишный макросный ад.
Получается, что автор столкнулся с прагматичной реальностью и отступил от своего принципа, чтобы не было "скрытой" логики, выполняющейся под капотом. Ну и ладно, так хотя бы реальные программы станет можно писать. Может, и ООП когда-то решится добавить.
>>1108633
У C/C++ есть некоторые родовые травмы именно в синтаксисе. Такие штуки как не всегда однозначный парсинг https://en.wikipedia.org/wiki/Most_vexing_parse который приводит к ошибкам программиста, или к долгой компиляции. Не просто так многие современные языки делают вот этот синтаксис где до объявления пишешь ключевое слово func, а после объявления и спец символа -> возвращаемый тип.
>Еще им, вроде, удалось сделать асинхронный код без покраса.
Насколько я понял, как раз не удалось, там был какой-то неявный автовывод компилятором, который был слишком запутанным, и переписывание IO как раз привело к отказу от этого.
>Получается, что автор столкнулся с прагматичной реальностью и отступил от своего принципа, чтобы не было "скрытой" логики, выполняющейся под капотом.
Речь и проблему скрытой/неявной аллокации и ошибок. Любой метод это абстракция.
Например можно написать базу с гарантированной работой (чел, который пропагандировал раньше раст и написал LSP для раста)
https://www.youtube.com/watch?v=NAOOGB1q6uQ
>Может, и ООП когда-то решится добавить.
ООП в системной разработки зло
Лезть в зиг или плюсы нужно только если ты собираешься свой движок собирать. Годотеру шарпов за глаза. Ты выиграешь 5-10% но будешь сидеть и побеждать системный язык. А если у тебя скрипт из чистых API лучше написать на гдскрипте.
>не всегда однозначный парсинг
Вообще не понимаю, нахрена в C-подобных языках указывается тип переменой и тип возврата функции задолго до самой переменной/функции? Мне вот на практике сначала известно имя того, что я планирую описать, а уже потом я думаю над тем, какой именно использовать тип/класс для хранения/возврата. Эта необходимость сначала указать некий тип для того несуществующего чего-то, что ещё не придумано, выбивает меня из потока. Как люди справляются с подобным неудобством в большинстве языков?
>современные языки
C - 1972, Pascal - 1970, ALGOL - 1960, Fortran - 1957. Современные языки просто вернулись к БАЗЕ, поняв косячность бредовой C-подобной фигни. Ещё бы все бесполезные скобки выкинули и писали нормально, литературным текстом, без лишних спецсимволов (машинный код, а не промпт галлюционирующему генератору псевдослучайных токенов в тексте).
В C# нет этих проблем. Это просто тупость автора языка, вроде указания переменных на стеке (Foo foo(10); ), которая создает эти проблемы.
> и писали нормально, литературным текстом
БЫТИЕ ОПРЕДЕЛЯЕТ СОЗНАНИЕ
Это написано литературным текстом. Теперь давай, распарсь, кто здесь кого определяет?
В C# всё то же самое - сначала тип, потом имя.
>>1108818
У тебя некорректный пример.
Вот более корректные сравнения:
ВАСЯ ЯВЛЯЕТСЯ ГЕЙМДЕВЫЧЕМ
МАША ЯВЛЯЕТСЯ ШКОЛЬНИЦЕЙ
ШКОЛА ИМЕЕТ МНОГО ШКОЛОТЫ
ФАЛЬКО ПРОИЗВОДИТ СЛОПЧИК
РОКСТАР ПРОИЗВОДИТ ГТАШКИ
Сравни это с:
ОТ ГЕЙМДЕВЫЧА ПРОИСХОДИТ ВАСЯ
ОТ ШКОЛЬНИЦА ПРОИСХОДИТ МАША
ШКОЛОТА МНОГО ИМЕЕТСЯ В ШКОЛА
СЛОПЧИК ПРОИЗВОДИТСЯ ФАЛЬКО
ГТАШКИ ПРОИЗВОДИТСЯ РОКСТАР
Вот вроде понятно, а звучит неудобно - запутывает.
В C# нет проблем с парсингом из-за этого, только вкусовщина (мне нравится)
>C-подобных языках указывается тип переменой и тип возврата функции задолго до самой переменной/функции?
Потому что матерые программисты в коде "думают типами", а ньюфаги думают "названиями переменных", а уже потом им редактор подсказывает тип - то есть, ньюфаги вообще не контролируют ситуацию.
Тоже самое с функциями, ты сначала думаешь какой результат получить, а уже потом что закинуть в коробку.
У тебя синдром утёнка, выучил паскаль в детстве и сидишь скобочек пугаешься.
Люди пытались сделать из языка программирования - естественный язык, но всегда получалась какая-то жопа.
Почему передвинули тип? Да потому что парсер удобнее писать, не от хорошей жизни, средний специалист тупеет, забытые технологии древних
Ты думаешь эти люди смогут написать ядро шарпов?
https://2ch.su/pr/res/3735926.html#3736033
>"думают типами", а ньюфаги думают "названиями переменных"
Тип данных может поменяться вместе с задачей, а название переменной меняется не так часто. Скажем, у тебя есть счётчик денег, который ты создал сначала как float, обосрался от ошибок с округлением и резко переделал на int, но потом узнал, что в твоём языке поддерживаются числа с фиксированной точкой, и снова переделал. То есть тип поменялся два раза, а название переменной осталось без изменений. Или ты сначала сделал индексы в форме строковых констант, обосрался от того, как долго происходит сравнение, переписал на int, потом подумал-подумал и переписал на enum, а потом обнаружил StringName и снова переписал на строки, но теперь без замедления. Опять - имя не поменялось, а тип поменялся 2-3 раза. Потому что задача строится как "что нам нужно", а не "через что это имплементировать" - нам нужны "деньги" или "индексы", а через какие типы данных эти вещи будут реализовываться - дело десятое. Ты не можешь контраргументировать в стиле "олдфаг не будет ошибаться" - во-первых, это лишь означает, что он подорвался на этом в прошлом, во-вторых, не допускает ошибок только тот, кто ничего не делает. Лучше пусть точная машина следит за ошибками, чем человек грузит своё wetware лишними самопроверками.
>сначала думаешь какой результат получить, а уже потом что закинуть в коробку
Сначала ты думаешь "что требуется сделать" - это глагол-название действия, который звучит наподобие "переварить"; потом ты думаешь "с чем это требуется сделать" - это объекты, над которыми действие производится, типа "еда", потом ты выбираешь тип этих объектов - "еда" (в данном случае совпадает, но может быть нам нужен только "фастфуд" или "здоровая пища"?), а только потом определяешь, что твоё действие в оставит после себя - "говно", или "обёртку", или "ничего", если у тебя 100% КПД пищеварения, способное переварить всё, включая обёртку. Было бы странно начинать описание своего действия с того, что тебе "нужен производитель говна", или "нужен производитель пустых обёрток", или "ничего не нужно, просто пустота", и только потом давать имя этому действию. Нет, соглашусь, что иногда тебе и правда необходим абстрактный "производитель говна", а не действие с объектами, но это специфичный случай.
>>1108831
>скобочек пугаешься
Они выглядят некрасиво и их труднее отличить от других видов скобок со слабым зрением и высоким PPI. На моём текущем мониторе я даже в очках пимпочки на "{}" не вижу, они выглядят как нечто среднее между "[]" и "()", поэтому с первого взгляда даже не понять, что там на самом деле. А "begin end" или отступы от края экрана видно сразу, даже без очков, даже при мелком шрифте с высоким PPI...
>Люди пытались сделать естественный язык, но всегда получалась какая-то жопа
Не знаю, о какой "жопе" ты говоришь, но подумай сам, что лучше:
>for Child in GetChildren do Child.Work; // Pascal
>for child in get_children(): child.work() # GDScript
>foreach (Node child in GetChildren()) { child.Work(); } // C#
>for (Node child: getChildren()) { child->work() } // C++
И т.д. Абсолютное превосходство Pascal очевидно - тебе не нужны ни "{}", ни "()", ни даже ":", и весь твой код читается как проза: "для каждого ребёнка из полученного списка детей приказать ребёнку сделать работу". Твой взгляд не "спотыкается" об избыточные спецсимволы и указатели типов. Просто и изящно.
>потому что парсер удобнее писать
Тогда почему не FORTH? Минимальная FORTH-машина умещается в 340 байт и это полноценный язык, способный с легкостью конкурировать с C/C++ по производительности и работать на любом железе без операционной системы. Его можно даже в древние чипы BIOS засунуть, целиком... ещё когда в них не запихивали аж десятки мегабайт под обновления. А если писать ОС, то FORTH-машина умещается в загрузочный сектор дискеты (512 байт) - и это всё, что тебе нужно, дальше только читать код ОС.
>Ты думаешь эти люди смогут написать ядро шарпов?
Пффф, обыкновенные "носочки программиста". Ты что, не надеваешь такие, когда код пишешь? А вдруг простудишься? У программиста комп мощный, сосёт как пылесос - и ветер прям по ногам дует. Тут без носочков не попрограммируешь никак. В полосочку или однотонные - это уже дело вкуса, не придирайся. Борода и длинные волосы - это тоже для теплоизоляции и терморегуляции головы. А в юбке мошонка не сдавливается и не перегревается... Не понимаю, почему у нас какие-то предрассудки против юбок - вот по какой такой причине бабам с пустой промежностью можно юбку, а мужики вынуждены сдавливать себе всё самое нежное и чувствительное, что природа специально вынесла наружу для охлаждения? У тебя никогда яичко не перекручивалось из-за того, что ногой в грубых штанах неудачно двинул? Это супер-больно. А в одних трусах не попрограммируешь по той же причине, по которой нельзя программировать без носков. Нормальные, здоровые, счастливые программисты в своей классической рабочей одежде.
И вот такие зашоренные шовинисты критикуют GDScript? То им отступы мешают, то носочки...
>Тип данных может поменяться вместе с задачей
Ну если ты ньюфажа ты буквально перебираешь возможности языка. А если ты PRO то ты обычно думаешь сигнатурами методов.
Пик, база баз, ты не должен знать кишки. Тебе нужна только сигнатура.
Единственное это когда вообще не знаешь что делать и делаешь "налету" (прототипируешь). И тогда тебе правда нужны только действие и именно поэтому js идеально подходит для быстрого прототипирования (помню школота даже не поняла о чем я говорил, опять трансформатор жужжит).
>Они выглядят некрасиво и их труднее отличить
Тебе не нужно их отличать, они нужны для форматирования - одна кнопка и все отступы раставлены.
В общем, синдром утёнка - развивайся.
>Не знаю, о какой "жопе" ты говоришь,
Смотри COBOL и прочую чепуху 1960-2000х (а может раньше)
Все что выжило - это продукт проб и ошибок - лучшее из худших.
>И вот такие зашоренные шовинисты критикуют GDScript? То им отступы мешают, то носочки...
Ни разу не говорил про синтаксис, я за всю жизнь на чем только не писал. В срачнике я даже сказал что синтаксис неплох, плоха техническая реализация - сдвиг миллионного массива в 45 раз дешевле чем оптимизированный свап-алгоритм на гдскрипте - это безумие (ты видел цифры на шарпе, какая должна быть разница). И самое страшное им насрать
За жизнь у вас будет только 1-2 языка в которых вы сможете сверх-шустро ориентироваться и комфортно писать. Поэтому стоит определиться.
При этом в инфраструктуре языка есть все нужные оптимизации, даже unsafe на арифметике указателей.
PS Кто не понял
>пик1
Проход по массиву без проверки выхода за границу на каждой итерации.
Но только надо проверять, потому что JIT делает больше чем вы думаете.
> У тебя некорректный пример.
Для иллюстрации неоднозначности натурального языка - вполне корректный. А у тебя наоборот иллюстрация корректных фраз.
> X ЯВЛЯЕТСЯ Y
Где "является" - это усовремененная форма словосочетания "являет ся", "являет себя", след древних словесных форм, существовавших в старорусском. И в этом смысле любое -ся определяет предыдущего. Вася являет себя как геймдевыч, но не геймдевыч являет себя как Вася.
Далее ты добавляешь еще больше частиц, всё дальше уходя от сути.
А суть в том, что если бытие определяет ся, то бытие первично, иначе сознание определяет ся. Эта фраза уже легко переводится на логичные языки программирования.
Но учтите, что если вы возьмете тройку и моно под веб/ios - моно интерпретатор будет убивать вашу игру на постоянной основе из-за вагона багов внутри самого моно, надо брать только четверку и фиксироваться на конкретных платформах, либо принять волевое решение и переехать на C++ godot 4, отличная работа в вебе, санитайзеры закроют проблемы по памяти, кодогенерация позволяет не писать руками тело bind_methods или описывать геттеры сеттеры а так же - ей же закрывается вопрос о рефлексии (clangast+своя реализация appdomain с хранилищем типов как в c#/il2cpp), std 20 модули для избавления от инклудов и шарпофикации импорта зависимостей, но - нужна нормальная тачка под компиляцию и сила воли это схавать
Не надо брать тройку, у него сломанный шедоумап и вагон багов с более низкой относительно четверки производительностью
>у него сломанный шедоумап
В чем это проявляется?
>вагон багов
Там наистабильнейшая 3.6.3 maintenance. Супротив 4-ки в которой еще не все даже существовавшее допортировали (хотя, конечно, добавили много новых фич)
>более низкой производительностью
Бенчмарки покаж. У меня другой опыт. Что на твг с десктопной на вулкане, что в вебе.
>В чем это проявляется?
В дырявых тенях на лоуполи геометрии у динамических обьедков, впринципе реализация directional освещения дерьмовая в тройке, в четверке щас нормально все и с тенями и с перфомансом
>Там наистабильнейшая 3.6.3 maintenance
Не на многопотоке, в отличие от четверки, где потоки в вебе могут сильно зарешать по перфомансу, в тройке апи многопоточное только в справке, а по факту - любые freeable операции делай только в главном иначе движок крякнет
>Бенчмарки покаж. У меня другой опыт. Что на твг с десктопной на вулкане, что в вебе.
Тогда придется игру показывать, а мне сильно неохота. Работаю щас с 4.7.2, буст по перфомансу куда заметнее против тройки, хошь верь хошь нет, но у меня основа глес, вулкан я не трогал так как веб целевая платформа
>еще не все даже существовавшее допортировали (хотя, конечно, добавили много новых фич)
А каких тебе фичей из тройки не хватает собственно? Просто интересно, не увидел ни одной такой которой в 4 не было бы против тройки.
Пойду потестирую потом, может что-то в новых версиях подкрутили. Но думаю размер билда все равно будет расти. На многопоток в вебе мне пофиг, там все равно дно устройства, максимум загрузку в фоне какую-то делаю.
Дыры в динамических объектах - ну хз опять же нишево. Проверь может у тебя баг при их создании какой-то, там легко напутать со всеми этими поверхностями, индексами. Может просто вывернулась нормаль наизнанку.
Не помню, периодически натыкаюсь на вопрос, собираюсь ответить что для этого же есть встроенный метод - а его не довезли. Да дело не в этом, многое заново переписали, поэтому нет доверия что там уже баги вылизали.
Ну размер билда да, немаленький, только васм плюсовый пакетик игровой логики у меня в оптимизированном состоянии весит почти 9мб, да плюс рантайм движка, где мне нечего резать, так что 15-20мб как минимум точно нарисуется. Но мне вес важен мало, игра может себе позволить забить хуй на вес клиента в разумных пределах, так как я сильно выделяюсь на фоне прочих браузерок
>На многопоток в вебе мне пофиг, там все равно дно устройства
Как раз на донных устройствах и надо выскребать всё из ядер, все что есть. Щас какой говнопроц не возьми - везде есть 4 ядра как минимум, надо поглощать.
>Дыры в динамических объектах - ну хз опять же нишево. Проверь может у тебя баг при их создании какой-то, там легко напутать со всеми этими поверхностями, индексами. Может просто вывернулась нормаль наизнанку
Ну может быть, но помимо этого еще и тени стали гораздо лучше в 4 сами по себе, практически без урона по производительности.
>>умный дядя еще не понял что они не хотят ничего писать
Не ну кто-то хочет, но под призмой максимализма лезет в плюсы или си (который по сути почти ассемблер).
Из-за веба лезть в плюсы - великолепный план.
Так по факту. Хочешь выбить предельную производительность? Добро пожаловать в клуб gdextension-данжен мастеров.
Если под вебом подразумевают свой сайт (не я.игры), то я бы вообще не брал ни один движок.
Есть подозрение что там колоссальное число оберток (на любом движке).
>И самое страшное им насрать
А почему должно быть не насрать?
Мы говорим в контексте выбора альтернативы гдскрипту
-если есть потребность написать сложные алгоритмы/системы,
-или если ты не хочешь за базовые операции платить микросекундами (вместо наносекунд, то есть в 1000-10.000 раз больше)
-и если ты раньше не писал на плюсах (лаба1.cpp не считается).
Вопрос в том куда ты хочешь инвестировать свое временя. Не все понимают реальную сложность С++. А если ты не хочешь учиться и вообще вайбкодя, то просто уйди в свои нейронки и загон /ai, не ровняйся с теми кто хочет учиться, твое мнение не важно в рамках инвестиции времени и сил
>А почему должно быть не насрать?
Ну тут вопрос что ты выберешь - практичность или удобство? Возможно ты как и я выберешь практичность выше удобства, поэтому тебе и мне было бы не насрать. Но если ты выбираешь удобство в ущерб практичности, у тебя даже цели не будет что-то изменить.
Вся надежда что годот обрастет сообществом и те продавят "практичность" (я кидал ссылки, такие потуги уже есть, люди пытаются, людям это важно. ).
>>1108390 →
>>1108391 →
Я бы не отказался от GDLang поставляющегося с отдельным компилятором и компилирующиегося в консольные утилиты, а к нему отдельно подключается редактор Godot и использует GDLang наравне с GDScript.
Я бы хотел, чтобы отличия от скрипта были минимальны, только в заголовочной части было бы import Godot. И был бы компилируемый язык с охуенным годотовым синтаксисом, который я обожаю. После гдскрипта питон кажется омерзительной поебенью. Всё что я вижу в нём похожего это только блоки отступами, в остальном ничего похожего. И при этом питон всё равно не компилируемый.
Самый ближайший к небесному годоязыку из существующих - это пока что Zig, посмотрите на пикчу от нашего железного друга. Это же буквально то, о чём мы мечтали долгими зимними ночами.
Тру стори. У меня в пайплайне даже используется несколько раз в год. Скрипт, который меняет иконку игры в релиз темплейте.
>Godot --no-window -s scripts/HelloCli.gd
Несколько лет знаю об этой фиче, но как-то не нашёл применения для неё. Если мне нужно что-то "автоматизировать", я либо .bat-скрипт напишу, либо AutoIt3-скрипт... Я могу понять, почему Python и похожие на него языки имеют "интерактивный режим" в консольке - ведь это "языки математиков", а математикам часто нужно какие-то матановские формулы считать, вот они этим и занимаются. А нам зачем? У нас матана никакого нет, то есть есть, но он такой, что в эксель-табличке проще посчитать, чем писать какой-то мудрёный скрипт...
>>1109054
>меняет иконку игры в релиз темплейте
Разве Godot не меняет иконку сам? Для Godot 3 нужно rcedit.exe скачать, а в Godot 4 вроде из коробки работает.
>>1109066
>генератор материалов по палитре
По-моему, это самый плохой подход к материалам. Ты должен делать наоборот: уменьшать число материалов, соединяя текстуры в атласы и/или используя текстуру-палитру с UV координатами, или какие-то ухищрения с Vertex Color делать. Как минимум если таргетишь OpenGL/мобилки; с Vulkan/DX вроде это уже не так важно. Также лучше использовать "instance uniforms" вместо создания отдельной копии материала для модификации каких-то параметров шейдера - это будет эффективнее, но, вроде, поддерживается только в Forward+.
А rcedit глючный. Дак в этом и фишка, зачем лишняя прога, когда есть скрипт на гдскрипте.
>Вася являет себя как геймдевыч, но не геймдевыч являет себя как Вася.
Правильно. Поэтому в нормальных языках ты пишешь так:
>class Vasya extends Gamedevich:
>_ func eat_and_shit(what: Food) -> Shit: ...
А в дебильных языках, описывающих всё через жопу - так:
>Gamedevich class public protected unsafe private anus-derned rejected heart-breaked Vasya {
>Shit public unsafe private anus-produced prolapsed method eat_and_shit(Food: what_the_fuck) { ... } }
По-моему, очевидно, что "литературный" подход для восприятия человеком лучше вывернутого наизнанку.
А уж что там приходится создателям компилятора/интерпретатора делать, чтоб это всё развернуть - нас не касается.
>>1108878
>синдром утёнка
>>1108880
>За жизнь у вас будет только 1-2 языка
Всё так: ты выучил этот C# и больше ничего не понимаешь, потому что тебя научили такому >>1108881 безобразию.
>>1108985
>что ты выберешь - практичность или удобство?
Значения русских слов забыл? http://ru.wiktionary.org/wiki/практичный
>выгодный, удобный по каким-либо своим свойствам, хорошо подходящий для решения каких-либо задач ценой сравнительно небольших затрат
То есть GDScript практичен, потому что удобен, а удобен потому, что позволяет решать многие задачи ценой сравнительно небольших затрат. А C# непрактичен, потому что заставляет перепрыгнуть через кучу различных совершенно не нужных ограничений ради абстрактной "скорости", которую и в GDScript тоже можно в перспективе завести, если поднапрячься (и вроде бы уже есть транспиляторы GDScript -> C/C++, так что можно не напрягаться), но в большинстве ситуаций современный компьютер решает задачи мгновенно даже на GDScript. Единственная ситуация, требующая более быстрый язык - это когда тебе позарез нужно тысячи единиц чего-то каждый кадр обрабатывать, но подобное в видеоиграх встречается относительно редко и чаще всего - уже полностью решено в ядре движка.
>нет доверия что там уже баги вылизали
Godot 4 начали делать более 4 лет назад, и уже более 3 лет он считается stable - на нём куча проектов и в разработке, и в релизе, в том числе в Steam. Если какие-то баги и остались, то это что-то очень специфическое, а значит, не критичное. У тебя какая-то фобия увеличения мажорной версии? На юнити и многих других закрытых движках владельцы движка крутят мажорную версию как и когда захотят, а с Godot ты даже сам можешь посмотреть исходники и решить для себя, много там критичных для тебя багов или нет...
>>1108925
>Супротив 4-ки в которой еще не все даже существовавшее допортировали
То, что есть в 3, но "не портировали" в 4, портировать уже не будут, потому что это не считается нужным для проектов на 4-ке. Лично мне вспоминается, что под конец 3-ки подвезли метод/ноду для "склеивания мешей", которая помогает решить вопрос с избыточным количеством дроуколлов в OpenGL. Но Godot 4 рассчитан на Vulkan/DX и дроуколлы экономит автоматически, поэтому возиться со склейкой мешей не нужно, если ты не пытаешься делать в режиме Compatibility. Но даже если тебе всё-таки нужна эта склейка мешей на 4-ке, ты можешь её легко реализовать даже на GDScript, потому что это тривиальная задача. В 3-ку эту фичу запилили только ради школоло-художников, которые не способны по массиву пройтись своими руками... А вообще, есть же Blender...
...вот эта нода: https://docs.godotengine.org/en/3.6/classes/class_mergegroup.html
Если есть что-то ещё, то мотивация там та же самая - в Forward+ не нужно, а Compatibility никто не обещал держать на уровне тройки.
>Это же буквально то, о чём мы мечтали долгими зимними ночами.
Ехал pub через pub, сунул pub свой var в fn, а там const .{.ц=ап} pub за var...
>>1109008
>Odin
Скочал, а потом посмотрел как оно в Godot вкручивается и думаю удолить.
> Поэтому в нормальных языках ты пишешь так:
Шаришь, бро! Вот за это гдскрипт и любим.
>>1109079
> Ехал pub через pub, сунул pub свой var в fn, а там const .{.ц=ап} pub за var...
Ну хотя бы паб разреши?
>>1109075
> >class Vasya extends Gamedevich:
> >_ pub func eat_and_shit(what: Food) -> Shit: ...
А хотя, я уже после того как пост отправил, нашёл гдскрипт-вэй решение. Все "паб" - это интерфейс, в его классическом смысле, а не в том, которым нагадили в современных языках. То есть, нам в листинге скрипта вообще не нужно никакие приставки методам прикручивать, все они по умолчанию должны быть приватными. А вот чтобы вынести то или иное наружу, его нужно объявить в интерфейсе (в заголовке). Примерно так:
> class Vasya extends Gamedevich:
> public:
> _ func eat_and_shit(what: Food) -> Shit
> _ var foo : String : get # объявили get-only свойство
>
> func eat_and_shit(what: Food) -> Shit:
> _ pass
>
> var foo : String = "" :
> _ get: pass
> _ set(v): pass
Несложно заметить, что выписанные в паблик определения полностью дублируют их определения в реализации ниже, поэтому будет логично вписывать публичные члены в интерфейсе/паблике/заголовке, затем дважды щелкать и редактор будет создавать копию внизу. Самая макотка такого подхода проявила бы себя в определении пропертей, в паблик засовываем только гет, а внутри прописываем и сет тоже.
>Ну хотя бы паб разреши?
На чужой лобок (pubis) не разливай фондюк (fondue).
>>1109083
Опять ты какой-то велосипед с квадратными колёсами изобретаешь...
Начнём с вопроса: зачем нужны эти public/private теги? Чтобы компилятор/IDE могла бы как-то сообщить другому программисту или нам-из-будущего, что вот эту вот фичу дёргать можно, а вот эту фичу дёргать нельзя/лучше не стоит. Ключевое слово - сообщить, так как запретить мы ему ничего не можем: желающий может просто залезть в исходники и переделать любой private в public, если ему это очень надо. Это просто такая условность, как запись зАбОрЧиКоМ или з_м_е_й_к_о_й, она нужна только для визуального ориентирования программиста на местности.
Далее, что нам важнее - public или private? Если мы пишем какой-то код, мы хотим его откуда-то вызывать, не так ли? Потому что невызываемый код нам нафиг не нужен. И даже если нам нужна только 1 точка доступа, мы можем захотеть получить доступ к чему-то кроме этого, например, в качестве теста или временного костыля-заплатки (впрочем, нет ничего более постоянного, чем временное). Поэтому очевидно, что начинать нужно с public, а как-то помечать только private.
Значит, нужен какой-то визуальный маркер для private, а public подразумевается по умолчанию. Почему бы... не начинать название со знака подчёркивания? Вот у нас есть eat(), который мы вызываем снаружи, а может быть _puke(), который вызывается изнутри автоматически, если нас накормили слишком сильно. Видишь, как просто? Всего один символ - и мы уже с первого же взгляда видим, что этот метод должен вызываться только изнутри класса - это его кишки.
Теперь мы можем настроить IDE так, чтобы она не выводила в качестве подсказки после "." поля, начинающиеся с "_", или загоняла их куда-нибудь подальше в конец списка. Помним о том, что мы не можем никому ЗАПРЕТИТЬ обращение, т.к. всегда можно поменять исходный код, и также помним, что иногда мы всё-таки хотим залезть в чьи-то кишки снаружи. Поэтому если кто-то и написал что-то вроде "person._puke()" - пускай оно выполняется, не проблема. Но главное - мы сразу видим, что этот код - костыль/заплатка, т.к. обращается к чужим кишкам - "_" в имени, и поэтому в будущем этот код нужно будет как-то переделать (отрефакторить программу).
И ты можешь не верить, но в Godot/GDScript это уже давно так принято и многими используется.
Да, действительно, так получается намного лучше. У меня буквально глаза открылись. Километры кода с кучей модификаторов типа private public protected sealed abstract были ошибкой. Нужно было делать всё публичным и просто ставить спецсимволы. Жаль что Хуан пошёл на поводу у этих, зашоренных, и ввёл @abstract - это буквально шаг назад к вот этим языкам!
Если на вкладке "Import" или в меню импорта модели нет такой кнопки, то нет.
Если нужно конвертировать очень много моделей сразу, можно написать скрипт:
https://docs.godotengine.org/en/stable/tutorials/3d/procedural_geometry/index.html
Можно даже свой импортер моделей сделать, если тебе это прям часто нужно:
https://docs.godotengine.org/en/stable/classes/class_editorimportplugin.html
Если модель одна или от силы десяток, то почему не сделаешь вручную в Blender?
Как-то вяло троллишь, старайся лучше.
>Километры кода с кучей модификаторов были ошибкой
Не путай айти энтерпрайз с их тысячами классов для тривиальной операции и суровый инди-соло-хобби-геймдев - бессмысленный и беспощадный, где запах свободы состоит из месячной немытости и смешивается с code smells.
>ввёл @abstract - это буквально шаг назад
Abstract нужен для наследования от общего предка-пустышки, он полезен в качестве предупреждения ошибок.
Задача: нужно 5 классов с одной функцией, у каждого своя реализация. Создаём класс-заглушку с чем-то типа:
>func do_something_generic(...args) -> GenericResult: return null
И в каждом потомке делаем то же самое, но вместо null возвращаем что-то полезное. Ноооо... спустя полгода решили добавить 6-й класс и ЗАБЫЛИ запилить эту функцию. Наш код валиден, проект запускается и никаких ошибок не выводит. Мы тестируем (если не забыли тщательно протестировать), и где-то через полчаса мы ВНЕЗАПНО натыкаемся на "whatever is null", из-за чего весь проект ломается. Приходится разбираться, что это и где нужно доделывать. Мы могли бы добавить самим-себе-из-будущего вот такое простое предупреждение:
>func do_something_generic(...args) -> GenericResult: assert(false, "implement this first"); return null
Но оно не вызовется, пока код не дойдёт до этой строчки, т.е. опять же тратим полчаса на тест. А вот если мы сообщаем компилятору заранее "это абстрактная функция, если ты её видишь - сообщи мне, что я забыл сделать реализацию этой функции в дочернем классе" - он предупредит нас сразу же, как только мы нажмём F5, и мы не будем тратить кучу времени на тестирование того, что в принципе не способно сработать по причине отсутствия.
Это не касается public/private, потому что обращение к private извне само по себе не влечёт к немедленным ошибкам. Конечно, код запутывается, превращается в "спагетти", копится "технический долг", но в общем и целом такой вызов может решать какую-то сиюминутную проблему (для хотфикса релизнутой с багом игры в ночь после релиза, например), поэтому этого следует избегать в нормальном коде, но ради "хорошей практики" не стоит засорять синтаксис языка, предназначенного для быстрого прототипирования игровых механик и склеивания различных API друг с другом.
В каком месте?.. Прости, я устал, поэтому невнятно пишу.
>может решать какую-то сиюминутную проблему ... поэтому этого следует избегать
Я тут как-то отвлёкся и собрал всё в кучу, лол.
Так... попробую так:
- маркер "private" нужен только программистам, а не компьютеру/компилятору;
- обращение к приватным кишкам приводит к запутыванию кода, а не к багам;
- запутанный код сложнее поддерживать, в т.ч. сложнее исправлять ошибки;
- но иногда такой хак может помочь быстро исправить критическую ошибку;
- поэтому не нужно запрещать хак, а маркер достаточен маленький ("_");
- "abstract" к этому не относится, т.к. предупреждает реальный баг.
Так понятнее?
Но это же скриптовый язык... И всего лишь в 45 раз медленнее чем нескриптовый. Даже не на два порядка. Зачем ждать от него скорости?
>И всего лишь в 45 раз медленнее чем нескриптовый. Даже не на два порядка.
Годотчую. Та же всемирно популярная Lua, кажется, в 150 раз медленнее C...
На реддите пишут, что простота не обязательно должна упираться в отсутствие возможностей. Поэтому там просят модификатор @private, ну, я бы согласился и на модификатор, так и быть. Подчёркивания в начале имён мне лично не нравятся.
C# с версии 10 можно юзать как скрипты (в том числе юникс shebang #! )
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/file-based-programs
> потому что тебя научили такому >>1108881 (You) безобразию.
Ансейв в расте - правильно и смелое решение, ансейвы в шарпах безобразие и ужасно. Какие же вы ведомые дебилы.
>>что ты выберешь - практичность или удобство?
>Значения русских слов забыл?
Если бы ты был программистом то знал что разработка языков это постоянная дилемма между удобством и эффективностью. Поэтому синтаксис часто неудобный там, где важна практичность.
То скобочки пугают, то модификаторы доступа. Ты точно разработчик?
Гдсрыге нет модификаторов доступа, потому что нет модулей, а не потому что гдскрипт такой прекрасный.
А модулей и неймспейсов нет потому что скрипт подключается как ресурс, в общем тянешь за одно место вылезает другое. При этом байткод настолько ужасен, что сдвиг миллионного массива в 45 раз быстрее свап-оптимизации (это без преувеличение безумие).
PS жопоскрипты и питоны критикуют за протекающую абстракцию и протекающую инкапсуляцию, а художники радуются этому в своем гдскрыге, ппц аборегены, с кем я тут сижу.
>Не путай айти энтерпрайз с их тысячами
Тысяча скриптов/классов для римворлд/факторио релиза выглядит как норм. Люди кроме демок ничего тут не делали, им чужды неймспейсы и модификаторы доступа.
>сдвиг миллионного массива в 45 раз быстрее свап-оптимизации
Можешь напомнить для тех кто уже потерял нить срача что это вообще за тест был и где смотреть код?
Где-то тут смотри SWAP тесты.
>>1106507 →
>>1106555 →
Чушь. Просто диды кодинга, писавшие первые компиляторы в далёких 60-70х не знали ещё тех подходов и оптимизаций, к которым пришли отцы 90х и 2000х. А те в свою очередь ещё не знали какие эффективные парсеры сделают сынки с внучками в 2010х.
Нахуя мне неудобства в написании кода, если компилятор сам выводит типы? Нахуя мне писать a := 0 если компилятор и из a = 0 выведет тип?
Нахуя мне писать скобки вокруг условия после if, если компилятор всё равно будет ожидать символ : который ознаменует конец условия и переход к подблоку?
Нахуя писать ; в конце строк, если компилятор и так знает, где концы строк?
И так в куче аспектов.
Языки буквально следуют моде, а не эффективности, про которую ты тут с умным видом талдычишь. Эффективность сегодня совсем на другом уровне. И самое интересное, большинство этих твоих настоящих программистов в упор не видят проблему в том что я тут написал.
Я когда-то видел в какой-то статье некое эмпирическое правило, как заценить что язык эффективен и его компилятор/транслятор/хуятор грамотно написан: Нужно написать программу в одну строку. Если язык нигде не потребует перехода на новую строку - он годный.
Вот и думойте.
Это как измерять качество программиста по количеству коммитов. Можешь не думоть, не твое.
>писать ; в конце строк, если компилятор и так знает, где концы строк?
А нафига ты точку в конце приложения ставишь?
>компилятор и так знает
Он нефига не знает, все его знания стоят времени компиляции.
Я помню в котлине ловили какие-то сложные баги с этой херней и до конца не решили их (я уверен из-за частичного решение там запихнули с десяток проходов).
>И самое интересное, большинство этих твоих настоящих программистов в упор не видят проблему в том что я тут написал.
Какие? Ты просто тот чело с аналогиями и графоманией, я тебя часто скипаю.
Ты из-за синдрома утёнка (вкусовщины) пытаешься раздуть проблемы синтаксиса. Это выглядит крайне не профессионально, как-будто у тебя в мозге проело паскалем или питоном. Как можно человеку что-то объяснить если он возмущается на модификаторы доступа? Это как возмущаться что у машины руль с лева, а не по середине. Наверное модификаторы доступа для чего-то нужны, да?
Если такой умный, собери свой парсер, да засунь в LLVM, сейчас каждый второй может создать свой язык, со своей шизой (этой глючной экзотики сейчас как грязи).
Не один язык до сих пор не решает проблему сложности, ООП с интерфейсами немного облегчает, но абстракции как текли - так и текут.
>Нахуя мне писать a := 0 если компилятор и из a = 0 выведет тип?
Это защищает от ошибки вида a = x; aa += 1; print(a)
В этом случае в некоторых языках заводится новая переменная, которая потом по тихому нигде не используется
Запись a := 0 это сокращение от a : autotype = 0, то есть это не только присвоение, но и объявление переменной.
>Нахуя мне писать скобки вокруг условия после if, если компилятор всё равно будет ожидать символ : который ознаменует конец условия и переход к подблоку?
Не знаю о чем именно речь, но там бывает много нюансов - вложенные if, какие-нибудь присваивания
>Нахуя писать ; в конце строк, если компилятор и так знает, где концы строк?
Потому что конец строк - довольно ненадежный ломающийся маркер. Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
> Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
>>1109181
> :
Как же достала эта хрень в каждом чихе. Серьезно, точка с запятой не так бесит как это, хз почему.
>Подчёркивания в начале имён мне лично не нравятся.
Эстетически? А мне вот кривые скобки не нравятся эстетически...
Ну, ладно, допустим, нужно твёрдо и чётко обозначить private. Почему бы не сделать это сразу для целого блока кода? Вот так:
>class MyObject extends Object:
>_ var public1: int
>_ var public2: float
>_ func create() -> MyObject: ...
>_ func do_at_public(): pass
>@private_part
>_ var private1: string
>_ var private2: Array
>_ func _ready(): pass
>_ func _process(): pass
>_ func do_in_private(): pass
>_ func _on_timer_timeout(): pass
>class MyOtherObject: ... # начался другой объект - приватная часть предыдущего завершена и закрыта, дальше снова публичное
И так далее. По-моему, это было бы проще и логичнее, и удовлетворило бы всех сразу без лишней писанины и переусложнения.
Если честно, я бы ещё блоки var и type вернул из Pascal в GDScript. Устал уже писать каждый раз var, const, enum и всё такое...
Алсо было бы полезно объединить все @export и @onready в один большой блок, чтоб не писать на каждой строке заново...
Да и, если честно, слово "func" совсем не обязательно каждый раз писать, если по заголовку понятно, что это функция...
>>1109126
>в расте
Я не знаю, что у вас там в этом вашем растишке, я его даже не пробовал. Увидел уродливый синтаксис и сразу пропустил.
>>1109127
>дилемма между удобством и эффективностью
Если ты пробовал создать свой язык программирования с нуля (как делал я), то знал бы, что удобство языка можно повышать без компроментации эффективности результирующего кода. Да, время компиляции может возрасти. Да, могут быть неочевидные конструкции, которые компилятор может сделать не так, как ожидает программист. Но результирующий машинный код никак не должен зависеть от того, как выглядит исходный код языка со стороны программиста. И язык не должен заставлять программиста задумываться о том, как лежат байты в памяти и какие операции выполняет процессор, пока он не пытается создать прошивку микроконтроллера с 16 КБ памяти на всё про всё и выполнить код в реальном времени как в какой-нибудь космической ракете. Большинство "неудобств" в существующих языках происходят не от "эффективности", а из-за необходимости поддерживать старый, давным-давно написанный код, т.е. чтобы твой "Компилятор v69.0" мог понять код, написанный во времена "Компилятор v0.01". Другими словами, кто-то когда-то сделал не слишком правильное решение, другие программисты были вынуждены применять это решение на практике, написав тонны кода, а когда нашли более правильное решение, оказалось, что нельзя просто взять и кинуть миллионы строк кода, полагающиеся на старое неправильное решение. Так языки и становятся уродливыми и неудобными. Ну, а большинство современных поделок зумеров - это буквально каргокульт, подобно создателям "убийцы ГТА" и т.п. - они способны написать рабочий код, но не понимают дизайнерской работы, которая стояла за созданием старых вещей, лишь копируя внешний вид.
Вот, кстати, наглядный пример карго-культиста в его естественном состоянии: >>1109128
>что сдвиг миллионного массива в 45 раз быстрее свап-оптимизации (это без преувеличение безумие).
Чувак в набедренной повязке на голое тело увидел "свап-оптимизации" в какой-нибудь книжке, и думает, что это какая-то священная техника, которая должна ускорять любой код быстрее скорости света, но его иллюзии разбиваются о суровую реальность, в которой реальная работа, требуемая для вызова функции интерпретатором в дебаг-режиме требует от компьютера больше, чем уже давно оптимизированный алгоритм, работающий в виде машинного кода на том же компьютере. То есть он буквально собрал "самолёт" из сухой травы и собранных палочек, танцует вокруг него и не понимает, почему с неба не падают большие ящики с провиантом.
>>1109129
>Тысяча скриптов/классов для римворлд/факторио релиза выглядит как норм.
Это совсем другие "тысячи классов": https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
>Люди кроме демок ничего тут не делали, им чужды неймспейсы и модификаторы доступа.
Делали. Нет, не чужды, но и не нужны (не обязательны - жить можно и без них).
>>1109150
Можешь не изучать, там школьник обмазался всеми проверками как по учебнику и удивляется, что они тормозят.
>>1109181
>Нужно написать программу в одну строку. Если язык нигде не потребует перехода на новую строку - он годный.
Ну, насколько мне известно, GDScript позволяет писать весь код в одну строку. Достаточно добавить ";" где нужно.
>>1109193
>А нафига ты точку в конце приложения ставишь?
Потому что он пишет несколько предложений на одной строке, и, кроме того, переносы строк (символы перехода на новую строку) в браузере для человеческого взгляда не видны явно, потому даже с переносами строк без точки или точки с запятой нелегко понять, где кончается одно предложение и начинается другое. С кодом всё иначе: код ты пишешь и читаешь через IDE, в которой переносы строк чётко обозначаются, а для компилятора/интерпретатора символы переноса строк видны так же, как и любые другие символы.
>Он нефига не знает, все его знания стоят времени компиляции.
Ты противоречишь сам себе в одном предложении... И что с того, что "стоят времени компиляции"? Компилируешь код ты один раз, а пользоваться результатом компиляции твои пользователи будут многие годы. Кроме того, медленные компиляторы - это не проблема дизайна языка, это проблема оптимизации компилятора. Если у тебя компилятор на JavaScript написан и выполняется через Electron, не нужно жаловаться, что он медленный, и тем более не нужно ломать удобство синтаксиса языка ради ускорения компиляции.
>Какие? Ты просто тот чело с аналогиями и графоманией, я тебя часто скипаю.
Ты серьёзно нас путаешь? Лол. Или я тебя чем-то так обидел, что ты меня теперь в каждом анонимусе здесь видишь? Расслабься, я не пытаюсь тебя обидеть или что-то вроде. Я только люблю спорить на всякие темы... это своего рода форумная игра.
>Это выглядит крайне не профессионально
Я никогда не называл себя профессионалом, и мы не на профессиональном форуме сидим, а на форуме хоббистов-самоучек.
>возмущаться что у машины руль с лева, а не по середине
Ты же в курсе, что есть машины с рулём по центру?.. А теперь представь, что у тебя в твоей личной машине висит книга по ПДД и специальная механическая рука бьёт тебя по лицу каждый раз, когда ты не зачитываешь вслух цитату из этой книги перед тем, как совершить описанное действие. Например, захотел повернуть направо? Сначала полистай книгу, прочитай вслух что-то наподобие "перед поворотом убедитесь, что дорога свободна, нет запретительных сигналов, и у вас включён поворотный сигнал", и только после чтения этой мантры ты можешь начать поворачивать, а если забудешь прочитать мантру - механическая рука разобьёт тебе лицо. И огромная толпа автомобилистов с разбитыми лицами защищает этот механизм, объясняя тебе:
>Как можно человеку что-то объяснить если он возмущается на механизм битья по лицу? Это как возмущаться что жидкое ешь ложкой, а твёрдое ешь вилкой. Наверное механизм битья по лицу для чего-то нужен, да?
>Если такой умный, собери свой парсер
Я уже делал несколько разных парсеров своих личных языков, мне пока достаточно.
>но абстракции как текли - так и текут
Абстракции текут из-за того, что ООП нужно учиться пользоваться. Язык не может решить твою проблему вместо тебя.
>>1109233
>Никогда не копипастил код с сайта или из чатбота
Аргумент уровня "никогда не пытался чистить уши кухонным ножом?" - сам себя поранил, а жалуешься на производителей ножей...
>>1109249
Лол, давайте ещё начнём жаловаться на то, что нужно ПРОБЕЛ нажимать.
>Почему нас заставляют нажимать ПРОБЕЛ? Можно ведь писать не просто в одну строчку, но и без пробелов! Ведь пробел после точки с запятой не нужен. И после "=", "+" и т.д. Но язык всё равно устроен так, что иногда приходится жать пробел. Это так плохо! Ненавижу пробелы! Хочу писать "a in b" и "a is b" без пробелов, чтобы компилятор сам догадывался, что значит "ainb" и "aisb", а то я на нажатие пробела драгоценные наносекунды трачу, которые мог потратить на просмотр порнушки или, например, мастурбацию.
>Если ты пробовал создать свой язык программирования с нуля (как делал я),
Не покажешь, да?
>И язык не должен заставлять программиста задумываться о том, как лежат байты в памяти и какие операции выполняет процессор
Что за бред, инты, чары, лонги, массив - это буквально указание того как лежат байты в памяти и что с ними можно сделать.
>>1109257
>Чувак в набедренной повязке на голое
Человек-аналогия, я не сразу тебя узнал.
Качество байткода гдскрипта напрямую влияет на производительность твоей игры, нафига ты маняврируешь? Если не поднимать проблему, то её никто не будет решать. Никто не говорит менять твой синтаксис, там качество интерпретатора хуже чем у питонов/руби, в этом проблема.
>Можешь не изучать, там школьник обмазался всеми проверками как по учебнику и удивляется, что они тормозят.
Школьник использовал больше if'ов чем положено, какая беспечность.
Скромнее надо быть, проверять аргументы хотя бы через раз.
>в дебаг-режиме
Тут ты уже лукавишь, гдсрыг в релизе дает чуть более чем нефига, это было проверено там же.
Подчеркивание у тебя в имени переменной, ты его всегда видишь. Это сразу сигнал - это что-то внутреннее, деталь реализации, это надо трогать только если точно знаешь, зачем.
>>1109269
Репорт.
>Не покажешь, да?
А смысл показывать тут, если это не касается Godot? Создание своего ЯП даже геймдева не касается.
>инты, чары, лонги, массив - это буквально указание того как лежат байты в памяти и что с ними можно сделать.
Тебе ещё многое предстоит узнать...
>Качество байткода гдскрипта напрямую влияет на производительность твоей игры
А у тебя и игры нет, чего ты волнуешься-то? Я вообще вкатился в Godot много лет назад, рассчитывая "по-быстрому накидать прототипчик, а когда будет играбельно - переделать на самодельный велосипед или более крутые библиотеки", но так за эти много лет и не пришёл ни к чему достаточно интересному концептуально, чтобы это имело смысл разрабатывать лично мне, а не играть в уже готовое (да я и в игры особо не играю). То есть я делаю прототип, вижу - скучно, бросаю его и думаю над тем, чем бы ещё заняться. О каком "качестве байткода" может вообще идти речь, когда упереться в нехватку производительности нужно постараться?.. Меня вообще из "тяжёлых" игр интересовала разве что Terraria, но в неё я давно наигрался и, попробовав её клоны и свои прототипы, понял, что это не моё. А всё остальное может и на GDScript потерпеть, ведь главное узкое горлышко - GPU.
>>1109272
База. Я вот привык почти всё начинать с подчёркивания, если мне это не нужно где-то снаружи вот прям сейчас.
> Подчеркивание у тебя в имени переменной, ты его всегда видишь.
Ладно-ладно. Стерпится-слюбится.
>Репорт.
Чего порвался то? От этого гдсрыг быстрее не станет.
Вахтерша протерпела два месяца, лол.
Все правильно тебя репортят. Хуйней страдаешь и тред дерейлишь на хуйню. Заменил движкосрач на языкосрач и типа хитрый дохуя.
>А у тебя и игры нет, чего ты волнуешься-то?
Ну, очевидно ты хочешь получить максимум.
У меня, кстати нет проблем с прокрастинацией как у вас, разработка это мое хобби (не важно что это игра или не игра, я все равно буду что-то писать, то есть я дропал прототипы по объективным причинам).
>Хуйней страдаешь и тред дерейлишь на хуйню.
Тебя поймал на лжи, от чего пердак порвался. Хватит прикрывать свои обиды тредом. Ты же умудрялся репортить даже в движкосраче, когда тебя возили лицом по некомпитентности.
Это не твой личный чатик, кому не нравится просто проигнорят.
Сейчас бы табулировать проблемы гдсрипта, которые подымаются везде.
PS
Забавно что начался учебный сезон, школьник опять сорвался и начал долбить в кнопку.
>тебя
Твой детектор настолько кривой, что дочитывать твое сообщение пойнта ноль. Я эту вкладку редко открываю, но каждый раз как захожу вижу тебя с абсолютно нерелейтед к треду хуйней. Так что тоже зарепорчу.
Вот в соседнем треде нет срача, там вообще уже ничего нет. Желаешь протухший тред? Как-будто кто-то будет спрашивать ньюфажные вопросы в эпоху ИИ.
>Никогда не копипастил код с сайта или из чатбота, или случайно не нажимал enter кружкой?
Сколько душу питона нейронкой - не было таких проблем.
мимо
Лол, это что ты натворил, чтобы тебя даже в движкосраче репортили.
>Лол, это что ты натворил, чтобы тебя даже в движкосраче репортили.
Он репортит за личную обиду, для этого не нужно ничего особенного - нужно быть технически неграмотным и иметь высокое ЧСВ.
Что за тред? Ну постят редко и пусть, как будто обязательно нужно доводить треды до бамплимита.
А вообще этот лампово и без срачей может жить
> базовой документации достаточно
Во первых это, во вторых ты проспал наступление эпохи ИИ. Твой личный ИИ-ассистент лучше любого учебника. Распишет и разжуёт тебе любую непонятную тему.
Ютуб плюс ии, больше нахуй не надо. У ии спраштвай не как сделать Х, а КАК ПРИНЯТО делать Х. Так и научишься
Для начала надо запилить низкоуровневый язык своей мечты, потом биндинги для него к годоту своей мечты. Только потом про игру помечтать можешь, но это не точно.
я к сожалению не могу в разговорный английский, а на русском ютюбе один скам, годных видео не нашел, так что начал читать документацию пока, вот про книжку мне как раз ии подсказал
> не могу в разговорный английский
Нейронка тебе переозвучит. Я тоже только англояз туториалы смотрю. Один раз смотрел испанское, и там была такая же хуня, как наши паштеты-фронтенды.
> вот про книжку мне как раз ии подсказал
Напиши ему, что тебе некогда читать книжку, пусть он тебе перескажет первую главу. ... ... Пусть он перескажет вторую главу... ... Сходил пописять. Выпил чаю. Пусть перескажет третью. И так далее.
У меня лежит в бэклоге, только пролистал её – на первый взгляд, пошаговые гайды по разработке пяти игр. Для новичков, наверное, пойдет (я сам - godot-мимокрок, обычно работаю на другом стеке).
Если что, на рутрекере есть пдф, может попробовать почитать его (и купить потом нормальную книги, потому что пиратство – это плохо)
>Chris Bradfield
Погуглил. Скачал какой-то PDF. Посмотрел - какой-то нейрослоп... Такое и даром не надо.
>хочу запилить рпг своей мечты
>или базовой документации достаточно?
Для освоения движка и примитивной аркады - достаточно официальной документации. Если программирование не знаешь пока, можешь ещё https://gdquest.itch.io/learn-godot-gdscript попробовать пройти - там на английском, но технический английский намного проще разговорного. Вся "сложность" английского в различных фразеологизмах, синонимах, сленге и т.п., что трудно найти в словарях и в буквальном переводе означает совсем не то, что тебе пытаются сказать. А "технический" английский - это более простые слова и обороты по чётким правилам, так что достаточно обычного англо-русского словаря и ты уже можешь читать любую документацию в оригинале.
Но для "РПГ мечты" (если ты буквально хочешь РПГ) твоим главным противником будет не движок, а сам жанр РПГ с его нюансами геймдизайна и создание визуального, литературного и прочего контента. Если бы ты хотел сделать простую аркаду/гиперказуалку, то там всё тривиально - есть "игрок" и есть "враги", игрок делает пыщ-пыщ и враги удаляются с экрана, добавляя +1 к счётчику очков, игрок чувствует удовольствие и ставит 5 звёзд из 5 в магазине. Жанр РПГ требует глубоко проработанный мир, сложные отношения правдоподобных персонажей, сюжетные и побочные задания со смыслом для игрока, "ролевую" прокачку героя, которая к тому же будет сбалансированной, чтобы игрок не был слишком сильным или слишком слабым, и просто море разнообразного контента, чтоб игрок не заскучал и не вырывался из погружения какой-то кривой фигнёй, которую ты случайно оставил в игре. Это всё не касается изучения движка, никакой ютуб-туториал тебя этому всему не научит достаточно подробно (там чаще всего чешут языком те, кто только и умеет что видосики снимать, чему они могут тебя научить?), да и в датасетах нейронок скорее всего недостаточно реально полезных данных, только общие советы и статьи журналистов.
Так что, чтобы не терять мотивацию, займись чем-то попроще, чем РПГ... или упрости свою "РПГ мечты": не 3D, а 2D; не с прокачкой в любом направлении, а фиксированные герои как в jRPG; не открытый мир, а набор локаций, соединённых в одну линейную цепочку с ответвлениями-тупиками; простой сюжет на классических тропах...
>>1109368
>>1109416
>ИИ, ЫЫ
Разве что спросить у нейронки конкретную статью в официальной документации, чтобы самостоятельно прочитать и вникнуть. Спрашивать у электронного лоботомита что-то напрямую — это просто выстрел себе в хуй, чесслово.
Это доказывает только то, что нейронка мыслит по английски (а то и по китайски) И твоё "сделай мне тайловую карту" переводит на "make me tilemap" что воспринимает как конкретное имя класса.
Это не значит, что нейронка плоха. Это значит, что ты - луддит.
>Это не значит, что нейронка плоха. Это значит, что ты - луддит.
Я даже представить не могу более нейронной фразы
>>1109530
Вы оба не правы. У нейронки недостаточно контекста задачи, именно поэтому никто уже не использует веб версии для вайбкодинга, а тупо загоняют агента прямо в проект, тогда агент хуйней не страдает а сразу понимает что хочет юзер, хотя иногда все еще пытается вместо drawable texture использовать вьюпорты или еще что-то в таком духе
> никто уже не использует веб версии для вайбкодинга
Ну, за всех не говори.
Я ни копейки не заплачу за обходы ограничений, чтобы юзать агенты. Мне вполне хватает низкоконтекстной клавдии в утке, а утка в браузере, а браузер в отдельном окне.
Не для того меня маменька растила нищебродом, чтобы я своими грошами поддерживал ИИ-пузырь.
Анон, никто не спрашивал о вайбкодинге и агентах. Новичок выше >>1109361 спрашивал о том, как ВНИКНУТЬ в движок и как обучиться в нем работать. Не о том, как использовать нейронки в разработке и не о том, стоят ли они вообще того, а о том, как научиться понимать, что там вообще происходит. Он вообще не спрашивал о нейронках.
Фанатики сразу насыпали ему полное ведро советов использовать ИИ, а мой тезис в том, что это хрень и нужно читать о каждом шаге самостоятельно, потому что ИИ насыпет новичку такой дезинформации, что он охренеет, попытавшись применить это на практике.
>Анон, никто не спрашивал о вайбкодинге и агентах.
Мне похуй, я не с ним общаюсь а с неосиляторами которых реплайнул
>а мой тезис в том, что это хрень и нужно читать о каждом шаге самостоятельно
Нейронки не отменяют этого факта, но читать нужно не код а математические и логические модели, которые описывает код, генерируемый нейронкой. Их действительно надо читать, спрашивать нейросеть что она насерила, удостоверяться в соответствии модель->код в том числе через тесты, а не читать каждый коммит. Впрочем, ебитесь с этим говном в вебе, никого не отговариваю
>Мне похуй
Все правильно. Нахуя отвечать кому-то по делу в тематическом треде, если можно просто влететь в двух ног в разговор, на которых тебе похуй и вставить свое ценнейшее мнение о том, как правильно генерить нейрослоп, когда речь шла даже не об этом.
Я всего навсего поправил двух неосиляторов, дабы они никого не вводили в заблуждение
Ладно, я привлек внимание модератора. Теперь можно забанить этого бота
>>1109621 →
>>1109477 →
>>1109450 →
>>1109431 →
>>1109400 →
и т.д.
>чтобы внутри рамки двери стена вырезалась через маску,
Не совсем понимаю откуда проблема возникла, дверь прозрачная в середине и через прозрачность видно стену, а ты хочешь чёрный прямоугольник?
Нет, я хочу, чтобы через дверь было видно пол, т.е. слой стены внутри дверной рамки вырезался с помощью маски. На пикче приложил часть тайлсета, как я понял двери с серым прямоугольником внутри как раз были предназначены для маски. Можно конечно сделать отдельные варианты стен с проемом, но это надо будет делать для каждой новой стены + каждой новой формы двери, т.е. их количество будет расти в геометрической прогрессии, а хотелось бы сделать универсально
Открой картинку в графическом редакторе и сделай серые участки прозрачными.
Но вообще у тебя уже есть такие прозрачые двери. О чем ты вообще?
Сделай тайл двери для стены. И тулом вставляй на сетку стен.
Блять... Смотри, красным я обозначил места, как должна выглядеть стена вне рамки, синим показал как оно выглядит при "прозрачной" двери без стены под ней. Если делать со стеной за дверью, то стена будет внутри дверного проема (желтая стрелочка), а там должен виднеться пол. Не знаю как еще понятней разжевать
>>1109959
Так это для каждой текстуры стены придется рисовать. Ладно, придумаю что-нибудь
Если правильно понял, ты хочешь примерно как на пике, ну я бы сказал что лучший вариант - делать дырку в стене, на неё уже накладывать дверь, т.е. нужно нарисовать тайлы стены с прозрачными кусками, на которые будет накладываться дверь
Ты тупой я тоже и это нормально
Сделай специальный "дверной тайл" обрезанный для двери.
Какие нафиг шейдеры.
Если стена будет только одна, сделай дверь сразу со стеной.
Я об этом уже писал здесь в последнем предложении - >>1109951, вообще первое что пришло в голову, просто хотелось универсальноти
Тебе придется и дверь разделить на две части если хочешь чтобы персонаж визуально проходил правильно.
>>1109972
>дверь разделить
Дверь мне запилите!
Может решение есть, но я бы не стал вешать шейдеры, чисто из гуманитарных соображений. Но опять же тебе надо решать как будет проходить персонаж (верхняя часть должна быть вне Y-сортировки).
>А в тридэ такие штуки лехче делаются, мдас хехс
Имитировать три-дэ в два-де всегда было сложным. Но модели делать все равно дольше чем эту дверь за 5 минут рисовать с разными стенами.
Неожиданно - но разработка игр это рутинная монотонная работа. Играть в игре веселее чем их делать.
>Шейдеры
Когда люди видят некро-графику, они ожидают что игра пойдет на их некро-компе.
Тебе просто утопят игру и ты даже не будешь знать почему.
>Но модели делать все равно дольше чем эту дверь за 5 минут рисовать с разными стенами.
От стиля зависит, я в блокбенче хуярю за пару минут и пиксельные текстуры там же натягиваю.
>От стиля зависит, я в блокбенче хуярю за пару минут и пиксельные текстуры там же натягиваю.
Тоже верно, но я пытался делать лоуполи с градиентными текстурами, а так как я не художник - визуально это выглядело хуже. А без опыта - дольше.
Как-будто для 2D у нас есть какая-то "скидка" по ощущениями, а плохое 3D уже режет восприятие. Да, я видел красивое лоуполи, у меня так не выходит.
Скорее всего я не прав и не хочу во всем этом детально разбираться (свет, фильтры, шейдеры итд).
PS
Cпасибо римволду я в разработке могу даже иногда на анимацию забить, если игра в глубину развита. А вот для 3Д на такую скидку рассчитывать уже нельзя.
Пикчи не мои, просто демонстрация как одно и тоже по разному воспринимается.
>демонстрация как одно и тоже по разному воспринимается
конечно, 200 фпс против 20 пс
Не понял, почему у тебя над дверью не прозрачность, а прилепленый пол.
Что касается шейдера, так ты и так используешь встроенный шейдер, как бы иначе Blend Mode Substract работал. Только еще и доп ресурсы тратятся на расчет псевдоосвещения
Не знаю с чего ты взял, что над дверью непрозрачность, внимательнее вглядись в текстуру пола - в тайлсете там прозрачность, а не пол. По поводу шейдера - да я понимаю, имел ввиду нужно ли будет ручками писать, я в этом не особо силен
Ты, блин, даже не описал игру, какой вид камеры.
Читай https://ru.wikipedia.org/wiki/Проблема_XY
По факту, ты сам себе проблему нашёл. Нафига тебе неполноценные двери, которые не вписываются в 2-4 отдельных тайла? Большинство тайловых игр имеют определённый размер тайла: 1 тайл = ноги героя, а 2 = полный рост, и соответственно все двери 2 тайла и перекрывают РОВНО два тайла пола и стен.
Но ладно, если тебе прям не терпится двери самых разнообразных форм, включая круглые, сердечки, зигзагообразные, и множество других, делай так:
1. Нода с кастомным скриптом, типа:
>@tool
>class_name Door extends Sprite2D
>@export_group("Textures", "texture_")
>@export var texture_door: Texture2D
>@export var texture_wall: Texture2D
2. В потомках ноды такая фигня:
>SubViewport
>_ Wall: Sprite2D
>_ Door: Sprite2D
Можешь создавать их в _ready скрипта.
3. Настраиваешь всё через код скрипта.
4. Используешь SubViewportTexture в корне.
Да, это может быть неэффективно, если у тебя там несколько тысяч одинаковых дверей с одинаковыми стенами (нафига тогда ты этим занялся?), но ты ещё недоделал игру, так что рановато оптимизировать... А доделаешь, заметишь проблему - вот тебе план Б:
1. Скрипт хранит Resource с Dictionary:
>class_name DoorDB extends Resource
>var key_count: int
>var keys: Dictionary[Sprite2D, Dictionary]
2. Когда юзер вбивает новый спрайт-дверь или стену, проверяем эту базу дверей, и если не находим пару, генерируем новую текстуру с помощью SubViewport:
>func get_walled_door(door: Sprite2D, wall: Sprite2D) -> Sprite2D:
>_ if door not in keys:
>_ _ keys[door] = {}
>_ if wall not in keys[door]:
>_ _ keys[door][wall] = generate_walled_door(door, wall)
>_ return keys[door][wall]
3. Функция "generate_walled_door" временно создает SubViewport с двумя спрайтами, делает "скриншот" и оставляет после себя только статичную текстуру (с прозрачной дыркой под пол, естественно).
Теперь у тебя эффективный генератор + хранилище вероятных комбинаций дверей, который эффективно использует и диск, и RAM, и ЦПУ/ГПУ, адаптируясь к конкретным условиям игры и данных. Без шейдеров!
>>var key_count: int
Игнорируйте эту строчку. Я долго думал над тем, как указывать Dictionary сразу два ключа, и только потом осознал, что мы можем же иметь словарь в словаре.
>Без шейдеров!
...полагаю, что для 100% универсальности, некоторый шейдер всё же потребуется, чтобы можно было взять абсолютно любые текстуры и вырезать дырку чётко в указанном месте - но этот шейдер будет простым и использоваться всего для 1 кадра в SubViewport, а в дальнейшем используется запечённая текстура.
Также возможно придумать массу усложнений, типа нормалмапов или анимированных стен, которые не запекаются так просто... Тут, опять же, нужно будет рассматривать требования конкретной игры. Часто пиксельные игры не имеют нормалмапы, анимации ограничены отдельными спрайтами (а тут тайлы)...
Классно! Вот бы принять тебя на работу в свою студию. К сожалению, у меня нет студии.
>плохое 3D уже режет восприятие
>демонстрация как одно и тоже по разному воспринимается
Ты выбрал пример, что в любом случае дерьмово выглядит из-за палитры.
>Как-будто для 2D у нас есть какая-то "скидка" по ощущениями
Возьми пипеткой цвета с твоей фотки и порисуй ими в 2D. Будет дерьмово.
c красотой перетолстил, буквально как в вк люди свои фотки лет 15 назад прогоняли через яркость/контраст и делали из лица сплошное пятно пересвета с глазками. Нужно 60% сероты и 40% второй картинки, и будет более менее.
Есть много популярных игр с пересыщенно кислотной палитрой и минимумом теней, и чуть меньше ч/б игр с большущим контрастом, но я практически не видел популярных игр с такой тусклой серотой. То есть, если стремишься сделать популярную игру, которая будет привлекательной многим - уж лучше не стесняться и обмазываться Color.RED, GREEN, BLUE, YELLOW, CYAN и MAGENTA, чем сидеть и выбирать серо-серый из сероватосерой палитры, даже если добавишь тени. В худшем случае назовут "кислотой", но разве люди не "кислоту" предпочитают, когда покупают лимоны и кисленькие конфетки? Люди обожают кислоту. Так обожают, что некоторые кислоты даже запретили...
Ещё бы я добавил в игру динамичное увеличение насыщенности и контраста после каждого убийства. Получается так: игрок наносит финальный удар, его противник регдоллится по полу, и картинка сразу поднимается на 150% насыщенности, постепенно возвращаясь обратно. Типа скачок дофамина у кровожадного героя, за которого игрок играет (что соответствует мотивации игрока, играющего в это).
Именно поэтому тот движкопися не смог сделать нормальную игру. Он стремился сделать банально реалистичную графику "на ЦПУ без ГПУ", а должен стремиться к нереальному игровому экспириенсу, независимо от того, чем и насколько ограничен.
Подскажите, что делать.
Редактор скриптов уже года два как минимум можно отделить от главного окна в отдельное окно и потом, например, скинуть на второй (вертикальный) экран. Функцию добавили примерно в то же время, когда появилась возможность создавать нативные окна (в далёком прошлом Godot не мог в нативные окна). А в последних сборках суть изменения в том, что главные "экраны" (2D, 3D, Script и т.д.) сделали равноправными с остальными доками редактора, чтобы можно было значительно проще делать всякие плагины.
>>1110331
>странное поведение
>100 тысяч рефкаунтов с сигналами
Таблетки от психиатра принимать пробовал?
Сигналы не предназначены для такого спагетти.
>>1110334
Щас он начнёт манёвры с "а вот в римврод..."
Я когда себе купил 2К монитор, у меня резко пропала необходимость отсоединять панели. Место есть для всего.
>когда появилась возможность создавать нативные окна
Отключаю в первую очередь. Как то нахапал неприятных багов в линухе.
>>1110343
А вот это тру. Да просто широкого моника тоже достаточно.
> Да просто широкого моника тоже достаточно.
И второй моник вертикально поставить, и в него отсоединённое окно со скриптами развернуть. Вот это будет МАКСИМУМ ДЕВЕЛОП!
>купил 2К монитор
2560x1080 или 2560x1440? Давно уже подумываю...
>>1110392
>И второй моник вертикально поставить
Эээх, у меня даже для одного места едва хватает...
>>1110353
>Отключаю в первую очередь
>нахапал неприятных багов
Понимаю, у меня на Windows тоже не гладко было - особенно в первых версиях 4-ки, когда выпадающие менюшки тормозили из-за того, что каждый попап - отдельное нативное окно с контекстом вулкан (лол)... Однако, сейчас вроде как все косяки давно сгладили.
Если в редакторе стоит галка "single window mode", отделение окна скриптов от своего места весьма бесполезно, т.к. оно остаётся в пределах основного, перекрывая другие, не менее необходимые доки.
> 2560x1440
Этот. Кадуши мониторов считаются по вертикали, с округлением в маркетинговую сторону.
>2K resolution is a generic term for display devices or content having a horizontal resolution of approximately 2,000 pixels.
>In consumer products, 2560×1440 (1440p) is sometimes referred to as 2K, but it and similar formats are more traditionally categorized as 2.5K resolutions.
Ясно. У меня 1440p еле-еле впишется под полку... И неизвестно ещё, потянет ли iGPU, или как игры будут выглядеть в 720p на такой диагонали... А так, очень хотелось бы расширить юзабельное пространство...
Диагональ там стандартная 16:9, а игры нынче все скейлятся прямо у себя во вьюпорте, выводишь в 8К, а по факту рендерится в 480, лол, а для старых игор можно и разрешение 720 выставить.
>Диагональ там стандартная 16:9
Лол, диагональ - это физическое расстояние между противоположными углами экрана в дюймах или в сантиметрах, а 4:3/16:10/16:9/21:9 и т.п. называют "соотношением сторон экрана". Но нагрузку на ГПУ вызывает количество пикселей, а не соотношение.
>по факту рендерится в 480
Так делают только когда используют апскейлер на нейронках, а это делает картинку странной и сильно нагружает видеочип, так, что оригинальная графика в большом разрешении может быть дешевле, лол. Я пробовал встроенный в Godot и мне не понравилось.
Что "анон"? Он сообщал контакты? Мне похуй. Анон и анон.
Если не ошибаюсь, "магнитола" (это скорее "бортовой компьютер" или "медиа-центр" называется теперь) предназначалась для какого-то концептуального российского электромобиля... "Атом", вроде бы? Хм, кажется, автомобиль уже пустили в серию - можешь поискать обзоры на него в интернете. Мне это всё неинтересно, так что разбираться не буду. Давай ты.
>>1110682
А разве это не тот лысый неймфаг из конфы, что ещё странными видосиками обмазывает каждый тред и постоянно воюет с какими-то другими неймфагами и модераторами, которых он лично ИРЛ встречал? Он, видимо, знаменитость локальная. Или это не он?..
Действительно интересно, учитывая что теперь такие приборные панели за один промт ебашут. Ну и времена.
Причем вместе с аппаратной схемотехникой и дизайном корпуса для 3д отливки...
Причём вместе с автомобилем, бюджетом...
>Гигачад, зделой так чтоп у нас усё было
И он подскакивает и сразу всё делает.
>>1110755
Хороший мем. Перефразируя:
>Luddites
"Тише едешь - дальше будешь".
>AI CHADS
"Живи быстро - умри молодым".
>Луддитя спок.
Что в других тредах совсем перестали отвечать на твои вайбкодь вбросы? Скучно, да?
Тогда спрошу тех, кто не занят(всех).
Вот есть допустим эта инверсная кинематика, в 3д если что. Так вот, глянул десятки туториалов, как используя эту канитель, делать так, чтобы персонаж, например во время бега по склону не просто проигрывал свою анимацию бега, а ещё и правильно ставил стопу и соответственно все что за ней следует (тут ik и работает). Дохуя чего устарело, в 4.6 разрабы что-то там правили/добавляли по этой шняге, короче теперь все не то.
Но не в этом суть. Суть в том, что нихуя не видел решений для братьев наших меньших (я про котов, собак и т.д. если что). Видал только где ноги правильно ставятся на, но без анимаций.
Короче, кто хоть чуть этим занимался/занимается?
Попробовал базовую хуйню внедрить - животное идёт вперёд и чуть заходит на условный камень, значит нога должна встать на него. Но просто все ломается к хуям, ногу косоебит под разными углами.
Пробовал исправлять, но лишь меняется степень и динамика косоебства. А лап ведь 4, и проблема вставания на уступ не самая сложная.
Короче, что делать, анон?
И да, раз пошла такая пьянка. Как лучше всего реализовывать физику столкновений? Из чего строить коллизии, например капсула для тела и рэйкасты для лап?
> не происходит.
Разгонять всех банами, а потом интересуются почему никто не пишет.
>Движкосрачя, спок.
Ты хотел сказать вайбкодя срач?
Туда еще кто-то заходит?
Чел со скайримом оказался пророком, ахуеть.
там и майнкрафт скрестили со скайримом...и с калл оф дути...
ох братцы... не к добру всё это...
Не надо гнать на Алису, её хорошо прокачали в последнее время
>пытаешься заставить IK решать задачу, которую IK решать не должен
Дальше эти галлюцинации можно не читать - предпосылка неправильная.
>>1110980
>Игори делаете чтоль?
Ты не поверишь, но нет, не делаем ничего.
>не видел решений для котов
Почти ничем не отличается от решений для гуманоидов.
>Но просто все ломается к хуям, ногу косоебит под разными углами.
Так ты сначала в редакторе мышкой подёргай за эту лапу, чтобы увидеть, как он будет гнуться под разными углами, прежде чем приделывать к ней рейкаст и блендить. Мне кажется, встроенный IK в Godot более требовательный к костям, чем в Blender. Если в Blender ты можешь навертеть кучу костей кое-как и оно будет как-то работать, то в IK Godot работало нормально только с 2 костями под определёнными углами. Так что ты, возможно, будешь вынужден сделать свой собственный IK solver для 3 костей, если в актуальных версиях Godot проблему 2+ костей ещё не решили (не интересовался, но вроде пытались).
Особенность многих четвероногих животных в том, что они ходят "на цыпочках", поднимая свою пятку так высоко над землёй, что она напоминает нам "коленку назад", тогда как реальная коленка часто близко притянута к животу - это добавляет им скорости или вроде того. Поэтому для реалистичной анимации тебе необходимо будет иметь 3 кости под IK, а не 2, как в случае гуманоидов, у которых пятка - точка опоры.
Но вот вопрос: а нужно ли тебе с этим всем возиться вообще? Это как регдолл - прикольно, но не более того, если ты не завязываешь на этом весь геймплей как в каком-нибудь Fall Guys. Твой игрок управляет четвероногим животным от третьего лица, постоянно заглядывая ему под жопу? Или у тебя там огромный четвероногий танк, занимающий половину экрана? И подумай о ландшафте: если это плоскости да редкие холмы, то IK будет избыточным; если это каменистые скалы, IK вряд ли сможет сделать положение ног действительно реалистичным из-за того, что всё тело должно балансировать как в active ragdoll. И также важна производительность. Что у тебя - 1 питомец на всю игру или 20 волков в стае? Сомневаюсь, что игроку понравится управлять стаей, которая тормозит всеми своими 80 ногами, пусть и "реалистично" касаясь каждого камушка на дороге. Плюс, ты должен будешь добавлять каждому такому камушку реалистичную коллизию, иначе весь твой IK будет совсем бесполезным. Хочешь ли ты этим заниматься?
Короче, это фича из разряда "было бы неплохо иметь, но у нас нет ни денег, ни времени, ни желания, а игрок эту фичу не заметит и не оценит по достоинству, а вот баги и тормоза из-за неё обязательно вызовут у него лютое бешенство, поэтому лучше забить и не вспоминать, пока не заработаем первый миллиард".
Их забанили за нейросрач и они ушли общаться с нейронками
Даже не забанили. Просто насмотрелись на местного душнилу-луддита и ушли.
>Их забанили за нейросрач и они ушли общаться с нейронками
Неожиданно, впервые адекватный банан.
База. А луддитины посты игнорируем, отвечайте ему, но вслух.
Да кто ж его знает, недоношенного выблядка вахтера гд. Просто по личной прихоти банит. Мучительного рака ему и всей его семье. Хорошим людям добра.
Это был залетный шизло-порватка, который вместо делания игр хуйней страдал и тред дерейлил на свои зиги. Вот тебе community poll, который разрабы годота ежегодно проводят. И доля GDScript растет от года к году, как и сам годот.
Меньше неумёх слушай. Они свои провалы на что угодно валят.
>дружелюбной, токсичной атмосфере
Тут только один конкретный индивид брыкается на весь тред, когда его справедливо банят.
>половина его хуесосят
Это всё один с синдромом утёнка на C#, которому байты считать для клона RimWorld захотелось.
>хотелось бы выжимку по фактам, чем так плох Gdscript
Откровенно "плохого" в нём ничего нет. Говорить, что он "плох", это как говорить, что "все ножи - плохие", когда ты пришёл с ножом на перестрелку и тебя ранили, а ты ни до кого даже не дотянулся. От того, что от ножа нет толка в перестрелке, нож не становится "плохим" - он просто предназначен для радикально других задач или ситуаций.
Начать нужно с вопроса "зачем нам столько языков программирования". Компьютер способен выполнять только простейшие команды, описанные порядковыми числами, которым можно дать ярлыки из букв, но суть от этого не меняется - ты по-прежнему пишешь код процессора по строгим правилам, которые оптимизированы для более эффективной работы процессора и могут отличаться между разными архитектурами и моделями процессоров. Поэтому на языках ассемблера (их много) мало кто пишет сегодня, если нет строгой необходимости в этом.
Чтобы устранить все эти проблемы ассемблера (трудность понимания человеком, оптимизация под конкретную архитектуру/модель процессора и т.д.) придумали более сложные языки программирования. Эти языки дают конструкции, более просто читаемые и понимаемые человеком, которые затем должны быть транслированы в машинный код - то есть код нужно перевести с человекочитаемого в машиночитаемый код. Сложность этого перевода сильно зависит от того, какие конструкции ты хочешь видеть со стороны человека и, конечно, от эффективности твоей программы-переводчика, которую сначала нужно написать на языке процессора (тут у нас возникает "проблема курицы и яйца", но в современном мире это уже давно не проблема для новых языков).
Так что все языки можно разделить по сложности трансляции из человекочитаемого вида в машинный код. По этой причине некоторые языки называют "низкоуровневыми" - они более простые, более близкие к ассемблеру по сложности своих конструкций - а другие языки называют "высокоуровневыми". Также иногда можно встретить названия "среднеуровневый" и "сверхвысокоуровневый", но это всё не важно. Важно понимать, что чем "выше" по этой шкале расположен твой язык, тем сложнее перевести написанный человеком код в машинные коды, и тем сложнее написать эффективный переводчик на машинный. Сложность может быть настолько высокой, что проще вместо буквального перевода держать при себе целый переводчик и "переводить" программу на ходу - то есть использовать "сценарий" ("скрипт"), которому следует сложная программа-исполнитель ("интерпретатор"). В некоторых случаях создать машинный код без промежуточного интерпретатора просто невозможно.
Другими словами, чем выше уровень языка, тем больше промежуточных команд процессора нужно выполнить для выполнения одной команды, написанной программистом. И не всегда эти команды можно оптимизировать, т.к. мы занимаемся разбором написанного на ходу, не видя дальше собственного носа - чтобы позволить программисту совершать различные трюки с кодом вне нашего поля зрения, которые просто невозможны (или слишком сложны), если записывать на языке машины (а современные ОС вообще запрещают делать подобное из-за риска вирусов).
И теперь главное: в некоторых случаях эти затраты оправданы, в других - нет, и поэтому нужно выбирать свой язык по ситуации. Иногда правильным решением является не использовать готовый чужой язык, а написать свой личный, самодельный язык, который будет иметь ровно то, что тебе нужно, но не более того. Впрочем, создать достаточно эффективный язык высокого уровня с нуля не так-то просто, поэтому с этим связаны свои проблемы...
Возвращаясь к Godot и GDScript, да и к геймдеву в целом: код большинства компьютерных игр можно разделить на тот, который должен выполняться 60+ раз в секунду и быть как можно ближе к машинному языку конкретного процессора, чтобы игра выжимала больше кадров в секунду на платформе игрока, и на тот, который может себе позволить тратить время на промежуточные команды интерпретатора, при этом требует сложных конструкций, понятных любому простому человеку - даже дизайнеру, а не только заросшему бородой сисадмину, пишущему программы для сложных систем намагниченной иглой прямо по поверхности системного диска.
Как правило, высокопроизводительный код игры называют "движком" - в нашем случае, это Godot. Такой код часто повторяется из игры в игру и поэтому его можно распространять как отдельный продукт, предназначенный для создания новых игр на общем фундаменте. Такой код пишется, обычно, не на ассемблере, а на C/C++, которые считаются языками "средне-низкого" уровня, и у которых самая богатая поддержка разных архитектур, поэтому их код легче перенести на другую платформу. Но писать "медленный" код для игры на них - довольно муторно для программистов, и чрезвычайно сложно для тех, кто не занимается программированием профессионально.
Поэтому многие игровые движки, и Godot не исключение, имеют в своём составе "скриптовый" язык, который может или не может компилироваться в машинный код. Возможно, ты знаешь, что наиболее популярным языком в старых играх была Lua - она и сейчас используется для многих игр. Также ты наверняка знаешь, что в Unity используют модифицированную версию C#, которую они только недавно научились компилировать в машинный код, а до этого были вынуждены полагаться на своего рода интерпретатор ("виртуальную машину"). В Unreal Engine есть урезанная версия C++ и визуальный язык Blueprint. Также можно отметить разные варианты ECMAScript, такие, как ActionScript из Macromedia Flash, JavaScript в некоторых движках и многих веб-играх, и покойный UnityScript из старой Unity. Некоторые платформы разработки игр имеют чрезвычайно высокий уровень скриптинга - такие программы чаще называют "конструкторами игр", как, например, GameMaker, Construct, RPGMaker, 001 Game Creator и многие другие.
Собственно, разработчики Godot решили пойти по стопам GameMaker и компании - создали свой собственный, персональный скриптовый язык "GDScript", который, тем не менее, обладает всеми свойствами полноценного языка программирования и может легко конкурировать с Lua и разными старыми версиями ECMAScript, и, разумеется, в разы лучше чего-то, что используется в ограниченных конструкторах игр. То есть это что-то промежуточное между "серьёзным" языком типа C++ и "игрушечным" DSL (domain specific language) из конструкторов игр. GDScript даёт каждому разработчику на Godot легко понятную запись логики игры, которая тесно переплетена с внутренностями движка Godot и легко редактируется через встроенный редактор кода (IDE, integrated development environment) в редакторе Godot (Godot Editor - то, что в чём ты обычно открываешь свой проект на Godot). Как можно понять из вышесказанного, преимущества GDScript несут в себе стоимость в виде более медленного исполнения кода - однако, для того, для чего обычно используют GDScript, высокая скорость выполнения и не нужна.
Но не нужно бояться "ограниченной скорости GDScript": в большинстве случаев, игра состоит на 99% из картинок, музыки и текста, и поэтому требует только уже реализованных в коде Godot алгоритмов, обращение к которым со стороны GDScript несоизмеримо быстрее их работы. Мало кому может потребоваться писать что-то на C++, чтобы создать полноценную игру, т.е. используя только GDScript для всех игровых алгоритмов. Более того, куда более вероятно, что твоя игра будет тормозить из-за графики или физики, чем из-за написанного тобой кода.
Отдельно стоит отметить причины реализации поддержки C# разработчиками Godot: во-первых, Godot зачастую рассматривается как замена для Unity, а пользователи Unity лучше всего разбираются в C#, во-вторых, Godot в своё время получил огромную сумму денег лично от Microsoft специально для реализации поддержки C#. Тем не менее, Godot поддерживает подключение практически любого другого языка программирования, и наилучшим языком для производительного кода всё равно остаётся C++ из-за более развитых компиляторов и готовых библиотек.
Так что пользуйся GDScript и ничего не бойся, а если вдруг будет нехватка скорости - смотри в сторону C/C++.
>>1111383
>Меньше неумёх слушай. Они свои провалы на что угодно валят.
База, именно такое ощущение от его постов (особенно в движкосраче).
>>1111389
Спасибо за развернутый ответ! Ну я как то тоже подумал, что язык эо всего лишь инструмент, собственно, как и естественный язык. Просто возникли сомнения так ли он замедляет. Ну и да, я тоже учусь на мини-джемах типа "клон RimWorld", но просто интересен ИИ. Примерные границы и даже что-то по оптимизации уже понял. Так, например, при 1200 простых FSM (на каждого генерится свой скрипт) появились просадки. И да, я знаю, что так неправильно, но во-первых на самом деле таких ИИ агентов не должно быть больше 10-15 по логике игры. Это было просто "испытание на прочность". Ну и да, FSM, конечно не пешка в RimWorld, там чуть посложнее, но в общем и целом, это был эксперимент. В принципе я быстро почувствовал, как именно это можно оптимизировать, просто это было не нужно.
Кстати, Lua я немного знаю тоже, но до Love2D не добрался. Слишком всё.. сложновато если честно для моего опыта. Но идея языка "всё есть таблица" оч крутая.
Пикча - ужасная статистика, которая говорит что разнообразия языков в годоте это миф. Я хз чему ты радуешься. Профессиональный разработчик видит тут вендерлок на языке у которого нет рантайма вне годота.
15% C# скорее всего реальный процент переехавших инди разработчиков, которые понимают что делают, вопреки неудобства шарпов как гражданина второго сорта.
Остальные - это показатель насколько реально комфортен GDE.
>zig
Это был другой анон, хз что у него там сложилось, но обычно программисты как раз и делают свои проекты, в отличие от мечтателей. У вас даже есть свой внутренний мем "безигорка", который отражает всю глубину проблемы. У кодеров таких проблем нет, мы тихо пилим и кайфуем от программирования, это наше хобби.
>Это был залетный шизло-порватка,
Так я замерил тестами, переписал листодробилки на шарпы и ушел делать игру. О чем мне еще писать? Я просто делаю игру, событий никаких нет. Я думал что буду делать быстрые прототипы на гдскрипте, а писать реальную игру на шарпах, но в реале полностью ушел в шарпы. Комфорт от привычного си-лайк языка оказался выше, чем плюшки от гдсрипта в редакторе.
На самом деле я не знаю улетал ли я в бан или нет, у меня роутер сам ребутиться по времени. Мне просто тред стал как-то противен, лишь раз в неделю забегаю поскроллить
>и тред дерейлил
>ряяяяя низя обсуждать шарпы, только гдсрыг!!!! ЗАБАНЮ!!!!
Ты походу тот вахтер с обострением, который умудрился убить единственный живой тред в гд. Теперь вместо технически грамотных анонон тут будут протекающие вайбкоди с глубиной знаний воробушка. Наслаждайся.
> Кстати, Lua я немного знаю тоже
Устанавливай и наслаждайся https://github.com/gilzoide/lua-gdextension
Продакшон левел!
Интересное обсуждение в комментариях:
https://www.reddit.com/r/godot/comments/1x0e9vk
Пост удалили, потому что автор унизил Unity Slop™.
Открыл, а он уже был мною апвоутнут. Это тот, который для перебежчиков с юнити? Иронично что годот, с его текстовым всем, нативно поддерживается нейронками лучше чем любой юнити/анрыл.
А вообще мне кажется в ближайшем будущем нас ждет капитальное перетряхивание геймдев сцены, и полностью новые AI-first движки.
Если бы ты не был тупым, то мог принести вижимку интересных по твоему мнению комментов и обсудить это с аноном.
Нет никакого желание погружаться в это и тем более искать там интересные комменты.
Если бы редотеры форкали годот сейчас, шансы успеха были бы гораздо выше.
О! Пригодится! Не в текущем проекте, но в одном из концепптова точно.
Если ты вдруг не знал, Godot позволяет выполнять произвольный код на GDScript прям в игре, из любого источника: файла на диске, интернета или просто так, обычного поля ввода (LineEdit). Конечно, нужно будет специальные инструкции выполнить сначала, но сам механизм позволяет дать игрокам инструмент для модификации логики игры прямо во время игры. Соответственно, отдельно ставить Lua не нужно.
>LineEdit
Алсо, кроме RichTextEdit есть ещё какая-то CodeEdit (не помню название), которая позволяет тебе встроить в собственную игру полноценный редактор кода, какой используется в самом Godot Editor. Правда, я не уверен, присутствует ли эта нода в стандартных release сборках - возможно, потребуется пересобрать export template.
По такому принципу построены обучалки GDScript и несколько каких-то инди-игр про кодинг на Godot.
Вкратце, Colobot у нас дома - прямо из коробки!
>вайбкодя чувствует НЕУДОБНОЕ
>начинает сразу с оскорбления
>добавляет боевую картинку
> Godot позволяет выполнять произвольный код на GDScript прям в игре
Какого-то exec'а вроде не было, а компилятор гдскрипта не уверен что входит в релиз сборки, инфа точная?
>компилятор гдскрипта не уверен что входит в релиз сборки
Компилятора вроде никогда не было, есть только интерпретатор.
>Какого-то exec'а вроде не было
Есть упрощённый аналог eval, вот тут подробнее:
https://docs.godotengine.org/en/stable/tutorials/scripting/evaluating_expressions.html
Но Godot также позволяет загружать любые .gd файлы и интерпретировать любой текст как GDScript.
Подробнее тут https://docs.godotengine.org/en/stable/classes/class_gdscript.html и в базовом классе Script.
А ещё, поскольку в .tscn и .res может быть упакован код на GDScript, который может исполняться в момент простой инициализации сцены движком (типа load("user://savegame.tscn").instantiate()), а не в момент какого-то действия с объектом, то если ты используешь tscn/scn/tres/res для сохранения-загрузки состояния игры, кто-нибудь, в теории, может написать вирус на GDScript, загружающийся в игру из этого файла, и модифицирующий новые файлы, чтобы отправить кому-то другому и т.д. Это вечная проблема скриптовых языков, тут сложно что-то поделать кроме как "не использовать tscn/tres для сохранения и загрузки игры и просить юзеров не брать файлы из небезопасного источника".
Но зато это позволяет делать игры "для программистов" и всякие интерактивные обучалки с реальным GDScript внутри.
>компилятор гдскрипта
А, вроде был какой-то в 3.x, но в 4.x его не завезли почему-то, что-то там сломалось у них.
Вообще, если тебе прям нужна игра со скриптами и в релиз сборке какой-то фичи не хватает - можно просто давать editor билд, он точно так же умеет запускать PCK, как и export template, просто он чуть жирнее и содержит в себе "потенциально небезопасные" фичи, наверное. Но для, например, моддинга, игры всё равно закидывают editor билд вместе с игрой, чтобы игроку не приходилось искать подходящую версию. Лицензия MIT позволяет делать что угодно с бинарниками, так что в этом нет никакой проблемы...
https://oceanofpdf.com/?s=Godot
И шапку добавьте
>есть только интерпретатор.
Если не доёбываться сильно, .gd файлы при экпорте превращаются в .gdc, ну типа compiled, там уже подготовленный байт-код
>Но Godot также позволяет загружать любые .gd файлы и интерпретировать любой текст как GDScript.
Вот тут не очень уверен, надо проверять на релизном билде, о чём изначально и написал.
>А ещё, поскольку в .tscn и .res может быть упакован код на GDScript, который может исполняться
Припоминаю эту тряску, что на Godot вирусы будут делать... Вообще делать сохранение на сценах - так себе идея.
>"не использовать tscn/tres для сохранения и загрузки игры и просить юзеров не брать файлы из небезопасного источника"
Как минимум можно не использовать текстовый формат, все форматы начинающеся с буквы t (текстовый) имеют аналог без неё - бинарный.
>Но зато это позволяет делать игры "для программистов" и всякие интерактивные обучалки с реальным GDScript внутри.
Если всё-же можно загрузить и выполнить любой скрипт, то могли бы дать флаг, чтобы это отключить и вообще можно сделать реестр скриптов с хешами и загружать только совпадающие.
>>1111634
>gd файлы при экпорте превращаются в .gdc
При экспорте можно выбрать экспорт скриптов чистым текстом...
>надо проверять на релизном билде
Проверил - запуск работает, но редактор кода нужно допиливать.
>можно не использовать текстовый формат
Какая разница, если скрипты могут быть и в бинарном формате?
>могли бы дать флаг, чтобы это отключить
Ну, каждый лишний флаг - это проверки, а, значит, замедление.
>>1111549
>CodeEdit
Эта нода хороша как фундамент, но это не весь редактор кода.
Сделай игру про подземелье, где я должен написать скрипт, чтобы победить всех монстров и собрать лут героем и спустится ниже. А в конце встретится с таким же героем из сети и биться за сокровищницу.
>Проверил - запуск работает
Понятно, будем знать
>каждый лишний флаг - это проверки, а, значит, замедление
Я видел это как флаг компиляции отключающий парсер, например
>написать скрипт, чтобы победить всех монстров
Подобных игр уже много, вот самая крупная:
https://en.wikipedia.org/wiki/Colobot
>...eliminating any alien life forms...
Статистика показывает, аноны ливают раньше чем упираются в возможности годота.
Сделать свой геншин (зачем? геншин уже есть) - по количеству работы это как построить самолет боинг 747 у себя в гараже.
У тебя шлема нет проверить? Годот умеет в WebXR, PCVR и автономный режим. Ты не определился с форматом VR походу же.
Небойсь даже Project Aincrad в VRChat не пробовал.
Почему бы не сразу гта 7 зделоть? Чет ты мелочишься, большой рыбы с тобой не поймаешь я смотрю.
> Появилась у меня мечта
У тебя обязательно получится.
> Осилит четвертый годот нормальный фпс
Осилит-осилит.
Тебе, в принципе, уже всё сказали, но хочется развернуть мысль. Поверь, ты сейчас плохо представляешь себе всё, что требуется для разработки даже небольшой, но хорошей 3D игры, которая по силам одинокому "на все руки мастеру". Ты же хочешь хорошую игру, а не тяп-ляп ассет-флип с кучей рекламы, который противно даже бесплатно скачивать, если ты уже не наивный ребёнок? Судя по тому, что тебя беспокоит частота кадров, ты хочешь хорошую игру (ассетфлиперы на юнити не парятся об оптимизации, отсюда эта репутация тормозной и глючной юнити). Но для хорошей игры движок - это самое меньшее, что тебе нужно, и движок по ходу дела не так трудно сменить, даже если придётся все скрипты игры переписать с одного языка на другой (это к вопросу о мнимой "закрытости" GDScript относительно других языков).
Большие игры начинают делать, определившись с целевой аудиторией (ЦА). Но тебе, как одиночке, нужно определиться в первую очередь с твоей настоящей целью. Ты хочешь сделать популярную игру, которая будет у миллионов игроков установлена? Можешь забыть об этом, если тебя привлекает игра, а не процесс агрессивной, лживой раскрутки игры в соцсетях и хищные методы, абьюзящие психологически уязвимых людей. Аналогично если ты грезишь о сверхприбыли. Если же ты мечтаешь о том, как будет прикольно играть в свою игру и добавлять всякое, не дожидаясь никого и даже наплевав на цензуру - то ты должен быть готов к тому, что до этой мечты пройдут годы тяжёлой, скучной рутины, и ты потеряешь желание заниматься этим много раз до того, как сможешь прикоснуться к тому, что ты себе навыдумывал. Реально дойти до финишной черты смогут лишь те, кому доставляет удовольствие вся эта неизбежная рутина.
Чтобы понять, что тебя ждёт, нужно сначала понять, что для тебя "клон геншина", а точнее - что именно ты планируешь копировать, а от чего готов отказаться. Большой проработанный мир? Десятки проработанных персонажей? Как мне кажется, мир геншина не заслуживает никакого внимания - он пуст и однообразен, это всего несколько красивых 3D диорам и километры однообразных препятствий, чтобы максимально затянуть геймплей. Но даже на одну такую 3D диораму у тебя может уйти несколько месяцев труда, а результат - "ну, прикольно выглядит" - и всё. Также и на одного персонажа может уйти несколько месяцев со всеми деталями и анимациями, ведь ты не хочешь кривой нейрослоп или чужие анимации, которые не подойдут твоему персонажу по характеру и стилю. Геймплей там посредственный, сюжет залит водой и катсценами, где 2-3 персонажа стоят кругом и чешут языком, озвучку ты не сделаешь в соло без кривого нейрослопа или бюджета на наёмных актёров озвучки. Что ещё остаётся? И зачем это делать в VR (пока мёртвая ниша)?
Но ладно, вот ты определился, допустим, что хочешь сделать красивую диораму с 1 видом противников и 1 персонажем, которым можно бить этих противников, 1 квестом без озвучки на зачистку локации от противников, и чтоб это было в VR от третьего лица (иначе зачем называть это геншином, если будет от первого лица?). Работа с движком у тебя займёт минимум времени, потому что это просто статичная моделька на фоне, маленькая группа тупых боксёрских груш и простенький контроллер персонажа по туториалам. Теперь открывай Blender, Krita и/или какой ты там 3D/2D софт предпочитаешь, и начинай рисовать. Сначала начни с концептов, которые нейронкой всё равно не сделаешь как положено, потому что нейронка не способна читать твои мысли пока что. Потом набросай из серых фигур эту свою выдуманную локацию в 3D. Закинь в движок, подвигай капсулу, чтобы прикинуть масштаб. Рисуй текстуры и потом муторно накладывай их, чтобы не было швов. Потом то же самое для персонажа и противника, но теперь тебе нужно ещё больше сил и времени на детализацию, а нейронки выдают ещё более стрёмный, ассетфлиповый результат, чем со статичными декорациями. Потом ты должен натянуть затекстуренные меши на скелет и разочароваться в свой жизни из-за того, как стрёмно это всё выглядит на сгибах. Долго править чисто техническую информацию, которую игрок вряд ли заметит. Потом делать анимации, делать и переделывать, потому что с первого раза ничего не получится как надо. И только потом проверять в геймплее, и снова переделывать, потому что ощущается как-то не так.
Пройдёт сколько-то месяцев такого упорного труда и ты сможешь пощупать свою сценку на одной статичной локации с одним персонажем и одним противником. При этом движок ты открывал разве что раза 2-3 в месяц, и написал от силы десятка два строк кода, которые выглядят почти одинаково на любом языке и любом движке. При этом у тебя всё ещё нет звуков, музыки и озвучки, а твой геймплей состоит из "пойди и закликай насмерть 20 статистов - убил? молодец". Допустим, ты начнёшь делать вторую локацию и ВНЕЗАПНО окажется, что Godot не тянет сразу две локации - окей, ты можешь взять Unity или UE или что там ещё создадут в ближайшие месяцы - и тебе нужно будет просто открыть этот новый движок, импортировать все твои модели с текстурами и анимациями и за один-два часа переписать твои пару десяток строчек кода с одного языка на другой. Молодец, ты мигрировал результаты многомесячного труда на новый движок, который даст тебе +5% фпс, но не сделает за тебя всю остальную игру, на которую уйдут десятки лет.
И это ещё не говоря о VR, который добавляет свой клубок проблем, поэтому и дохлый до сих пор, несмотря на то, что технически технологии VR существуют почти столько же, сколько существуют видеоигры в принципе. Это всё ещё такая же зародышная фигня, что и прежде, со своими детскими болячками, брошенная многими техническими гигантами. До полноценного VR ещё далеко, поэтому тебе придётся не только игру делать, но ещё и бороться с технологией.
Короче, ты беспокоишься совсем не о том. Тебе бы не в /gd/, а в /td/, чтоб тебе пояснили, как сделать "геншин".
Какие 10 лет, люди с нормальным ии уже за неделю делают клон тераррии почти со всем контентом кроме боссов - https://www.reddit.com/r/aigamedev/comments/1wywfri/claude_opus_55_rebuild_terraria_in_3d_custom/
Ну удачи там. Сидишь такой "ИИ мене надо то..". Охуительный ты разработчик... А на деле тупо незнайка, неумейка и ленивоче чмо. Инди - это о тех, кто любит красноглазить и создавать руками. Это творческий процесс. И, да, уточнить у ИИ моменты, в целом полезно. Но, точно вредно, если не ты, а ИИ делает игру. Получается, что ты вовсе и не создатель в этой картине.
Врети, нейронки в собственных ногах путаются! Ничего не могут!!1
Мне кажется давно уже стоит разделять эскапистов геймдевов и творцов. Эскаписты это в основном красноглазики, которые там движки с нуля создают и прочим непотребством занимаются, кроме непосредственно созданием игр. А творец он на то и творец, у него его видение и он ебашит, а как это уже другой вопрос.
Занятно ты свои слабости пытаешся прикрыть переворачивая мои слова.
>и он ебашит, а как это уже другой вопрос.
С потом на лице забивает промпт, напрёженно ожидает ответа ии?
Ебашит... Ага... угу
У нас творцы по старинке ебашат, на тех инструментах к которым привыкли. Парадигму сложно менять, даже если новая быстрее, к этому привыкать ещё надо, новое это всегда стресс.
Я свои старые проекты ии отдавать не спешу, мне просто удобнее там контент пилить без его вмешательства.
А если вбить неправильный код, отловить ошибку не засрав консоль и выдать юзеру сможешь?
Перестань оправдывать свою лень. У тебя ж логика - "не хочу потеть, хочу бабки лутать". Моя же при этом - "придётся попотеть, но это то, что для меня важно". В этом мы с тобой разные. Да и в целом не смогу никогда понять, какой кайф от пользования ии? Ты не ломаешь голову, как накостылить или избавиться от бага. Мой кайф от процесса, каким бы он не было, лёгким или сложным. А твой в чем?
>не засрав консоль
По-моему, в релизном билде вывод в консоль может отключаться.
>отловить ошибку и выдать юзеру
Ну, метод Script.reload() возвращает какой-то код ошибки...
>сможешь?
А я-то тут при чём, лол. Кому надо - тот разберётся...
>Terraria in 3D
Когда "Minecraft clone" уже не даёт достаточно лайков для повышения ЧСВ в соцсети...
Вот только тот анон выше спрашивал про "геншин импакт", а не "пиксельный рыгалик".
>>1111924
>Охуительный ты разработчик
Да пофиг на них, они - личинки кабанчика, у кого не хватает смелости с людьми работать.
>>1111931
>А творец он на то и творец, у него его видение
В том-то и дело, что добиться от Generative AI реализации твоего видения почти невозможно.
>>1111937
>новая быстрее
Если цель жизни - это смерть, то не лучше ли было бы суициднуться, и как можно скорее?..
>>1111940
>У тебя ж логика - "не хочу потеть, хочу бабки лутать".
>Мой кайф от процесса, каким бы он не было, лёгким или сложным. А твой в чем?
Он кабан - управленец, его кайф - управлять людьми. Но ещё он двачер - боится людей...
Код это не та часть игры на которую стоит тратить свое драгоценное время, если только это не твое хобби - кодить (а не делать игру) или ты делаешь какие-то еба-механики без графена. Ты модели рисовать замучаешься и это ИИ уже не отдашь (или отдашь и мучайся потом с ретопом кривого говна ручками).
>Код это не та часть игры на которую стоит тратить свое драгоценное время
Какое "драгоценное время" ты тратишь? Мы в Godot-треде, а не в движкопися-треде вообще-то.
Зашел снова чтобы сказать, что тот анон был прав, в годот модели лучше импортировать через gltf-файл (именно gltf с текстурами рядом, однофайловая glb упаковка нихуя нормально не работает). Кидать упакованный blend-файл это действительно какая-то ленивая залупа, которая постоянно плодит мусор, а так же регулярно разъебывает настройки материалов и пути к текстурам.
Все, идите нахуй.
Привет-привет. Как шкаф?
>Зашел снова
Да ты и не уходил никуда...
>тот анон был прав
А чего ты ожидал-то, салага?
>Все, идите нахуй.
И тебе счастливой доставки!
Похоже, ты ошибся движком
>люди с нормальным ии уже за неделю делают клон тераррии
Это твой уровень - наличие ии, кривой код, ворованный концепт? Прискорбно...
>>1111966
Ребят, ну, давайте не издеваться над детишками. Ну, тред любви же всё-таки. Движок наш специально адаптирован для детей, зачем прогонять? Вы сидите на детской площадке, вокруг детские качели, песочница, всякие забавные зверушки и т.п. Приходят дети с модными игрушками - ну, там, спиннеры какие-то, или как это ещё называют... не важно; а вы им говорите "похожие, ты ошибся площадкой", "твой уровень - сидеть дома и играть в кубики", и тому подобное. Вам самим не стыдно? Как бы вы отреагировали, будь вы в их возрасте? Серьёзно, это может их травмировать. Вырастут агрессивными, обиженными на весь мир.
Давайте не гейт-киперить игровое (геймдев - это про игры всё-таки) хобби и не сраться.
Уже украл идею, уже приступаю к разработке, уже запросил у ИИ обложку для пиара. К утру заработаю свой первый миллион!
Расскажешь потом сколько токенов сожрало. Астра надеюсь или решил сэкономить?
Ну, может я и переборщил с резкостью разговора, но никого не прогонял. Про Юнити ИИ - скорее юморочек к теме был. Ну, а в цедом, постораюсь быть бобрее.
Мне кажется, любое хобби склонно к гейткипингу, прув ми вронг...
Вот и вся разница, самые главные люди в геймдеве это геймдизайнеры, люди с видением и это не только в играх это влюбом искусстве так, потому что все понимают что игру не делает не тот кто кодит, а тот кто видит всю картину целиком как коджомба или миядзаки, которые за всю жизнь ни строки кода не написали.
Автор регулярно постит то, как он это все делает, на r/godot. Я пару раз приносил его видосы в ИТТ. Сходи-подпишись-почитай. Игра на годоте, да.
ну в геймдевелопе все важно. Без кода перс не сдвинется с места. Без изображения игрок ничего не увидит.
Если это к тому, что ии справляется с кодом, то беда в том, что не справляется. И творческого смышления у ии нет. И, вот ещё о чем подумай, когда шарик с ии лопнет, где во всем этом окаэжешся ты? Я не потеряюсь ибо сам себя учу. А ты?
Вот прям используют ии, поголовно... ага угу...
Глобально все движки похожи: майнлуп с коллбэками. Набор утилит и функций же различаются кардинально, прямых соответствий минимум. То есть на низком уровне 1-в-1 ты код не сконвертируешь, но на уровне логических абстракций вполне реально одни блоки заменить другими, самостоятельно написанными под эту задачу.
Ассеты портировать вообще самая сложная часть. Тут к языку добавляется куча конфигов, которые вообще не будут совместимы. С другой стороны, если ассеты изначально держатся в стороннем софте умеющем выдавать готовый результат общепринятого формата, например GLTF, то и портировать много не придется.
Изучив одно тебе будет немного легче в другом, но там разная инфраструктуры и API. Например ты понимаешь что тут нужен какой-то рейкаст и ты идешь спрашивать/читать как сделать это в движке n.
Но делаться это будет немного по разному.
Например в годоте навмеш доступен для 2D, в юните нужно "сделать бочку" из сторонних либ чтобы родной навмеш юнити заработал на тайлах (там еще ручками надо задавать непроходимые участки и все выглядит так что тебе надо будет курить сорцы сторонней либы и возможно частично её переписывать, потому что для процедурного динамичного мира это все не пойдет).
Бесполезно. Нижеописанный код неспособен отловить ошибку. Если это возможно, и я где-то накосячил, сообщите. Иначе, для любого использования в игре нужно писать свой парсер такой же как годотпарсер, т.к. ошибки не отлавливаются без краша приложения.
using Godot;
using System;
public partial class GameScript : RefCounted
{
private GDScript _script = new GDScript();
public Godot.Error SourceCodeSet(String source_code) {
_script.SourceCode = source_code;
return _script.Reload();
}
public String SourceCodeGet() {
return _script.SourceCode;
}
private String _error = "";
public String ErrorGet(){
return _error;
}
public bool Run() {
RefCounted rf = _script.New().As<RefCounted>();
if (rf.HasMethod("run") == false) {
_error = "Script not has method run";
return false;
}
try
{
rf.Call("run");
}
catch (Exception e)
{
_error = e.Message;
throw;
}
return true;
}
}
>rf.HasMethod("run") == false
Чтобы такого безумия не было нужно использовать интерфейсы.
Я работаю с динамическим кодом юзера. Он может сделать что угодно с файлом. Но если там ошибка, падает весь годо. И трай Кетч не пашет.
Ну вообще-то он пашет, как ему и положено, но ты же сам написал там throw; это слово бросает ошибку наверх, а наверху годот, который не ожидает возврата ошибки. Поэтому он падает.
Тебе надо не бросать ошибку, а обрабатывать.
> try { return 123.0 / 0 } catch (e) { if (e == DivideByZero) return NaN; }
Вот этот код не распространяет ошибку наверх, а обрабатывает её.
Ты же знаешь как работать с ошибками, да?
Это автокодер. Я убирал эту строчку и не помогло. Падает главный поток годо, а не шарповый скрипт.
Нуу... Значит... Остаётся только пожелать тебе добра и отыскать проблему. Добротред же!
Уже сейчас можно играть онлайн 1 на 1.
Тест актуален всегда. Напиши — скину билд.
1pa9c6zslsoh@mail.ru
да второе прищесвие,ту забросил, это совершенно новый проект, но до сих пор дизайн от программиста, надеюсь нейронки это исправят
Здравствуйте ребяты, подойдет ли Годот для пикрила?
Чтобы добавить это в годот нужно создать ноду Sprite2D.
Не благодари.
Вопрос на счет работы с плагином Terrain 3D.
Как правильно оптимизировать работу с плагином, если я хочу запекать лайтмапу по террейну + иметь удобный скульптинг и покрас (в чем и есть смысл плагина)? Ведь геометрия у terrain3d не участвует в запекании - придется работать с динамическим освещением, что не ок, плюс, сама по себе отрисовка террейна на GPU тяжелая. Хочу оптимизацию.
Пока такой пайплан вижу:
1) Скульптинг в Terrain3d
2) Запекание меша 1к1 (LOD 0) по геометрии террейна
3) Экспорт в Blender
4) Покраска в Blender (Texture Paint)
5) Нарезаю отдельные куски
6) Импорт в godot
7) В годоте коллизию делаю Trimesh
8) Закидываю все в одну сцену
9) Запекаю свет и тени
Подводные?
---
Godot 4.5
Регионы в Terrain3d = 64 на 64, vertex spacing = 2.0.
Планируется от 2 до 6 регионов на сцену.
Да вроде не должно подводных быть. Отпишись как прошло.
И я бы заготавливал террейн в специализированных приложухах WorldMachine, а в плагине только финишно подправлял.
Потому что спрайты это точки, из которых движок отрисовывает текстуру назначенную. И сортировка сортирует именно эти точки, а не текстуру, которая там отрисована. Это надо учитывать. Ты учитываешь?
Да, благодаря Анону выше пофиксил. Сейчас вопрос с навмешем - почему-то обход препятствий не работает. Видимо - это только изменением навмеша в реалтайме делается. Или нет?
Почему твои кнопки пытаются убежать из-под курсора, а их текст - из-под взгляда? Это игра "выбеси меня"?
Там кнопки не убегают, наоборот становятся больше. Для меня выглядит как комиксанс мира анимации. Добавляет игре детскости и простоты.
Говорит,что годот не может отлаживать,потому что подключен к порту.И по этому порту происходит отладка.Но отладки не происходит внутри браузера,не получается соединиться по порту.Скачивал веб-версию и запускал под xampp и работало все кроме отладки.Включал https://editor.godotengine.org/releases/latest/ под тором(под обычным браузером не работает(заблокировано),а vpn плохо работает),и под тором он отказывается работать.Это просто эксперимент,запустить годот под веб.Но наверно не получится.Много пердолинга,того не стоит.
Отрицательный результат - тоже результат!
>>1112454
Я уже сонный, есть шанс что не понял твою проблему, но банально f12->console в браузере смотрел?
там выдается такая ошибка
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
может быть порт занят?Я хз вообще.Такое выводилось и в консоли ошибок годота.
вот полный вывод
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE godot.editor.js:488:18
onPrintError http://127.0.0.1:6010/godot.loc/godot.editor.js:488
put_char http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
doWritev http://127.0.0.1:6010/godot.loc/godot.editor.js:7
_fd_write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
<анонимный> source19:25817979
<анонимный> source19:9497181
<анонимный> source19:6722534
<анонимный> source19:29047884
<анонимный> source19:3444469
<анонимный> source19:29048347
<анонимный> source19:29047607
<анонимный> source19:408029
<анонимный> source19:401610
<анонимный> source19:3441185
<анонимный> source19:41562155
<анонимный> source19:8875488
<анонимный> source19:8631484
<анонимный> source19:11706093
<анонимный> source19:40097321
<анонимный> source19:599776
<анонимный> source19:716019
<анонимный> source19:28789702
<анонимный> source19:716019
<анонимный> source19:13503522
<анонимный> source19:37260583
<анонимный> source19:6150450
<анонимный> source19:37121492
<анонимный> source19:6121223
<анонимный> source19:4357389
<анонимный> source19:3590845
<анонимный> source19:11161264
<анонимный> source19:839896
<анонимный> source19:716019
<анонимный> source19:23167365
<анонимный> source19:41458433
<анонимный> source19:5662026
<анонимный> source19:2980944
<анонимный> source19:43814798
button_cb http://127.0.0.1:6010/godot.loc/godot.editor.js:7
at: listen (core/io/tcp_server.cpp:57) godot.editor.js:488:18
onPrintError http://127.0.0.1:6010/godot.loc/godot.editor.js:488
put_char http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
doWritev http://127.0.0.1:6010/godot.loc/godot.editor.js:7
_fd_write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
<анонимный> source19:25817979
<анонимный> source19:9497181
<анонимный> source19:6722534
<анонимный> source19:29047884
<анонимный> source19:3444469
<анонимный> source19:29048383
<анонимный> source19:29047607
<анонимный> source19:408029
<анонимный> source19:401610
<анонимный> source19:3441185
<анонимный> source19:41562155
<анонимный> source19:8875488
<анонимный> source19:8631484
<анонимный> source19:11706093
<анонимный> source19:40097321
<анонимный> source19:599776
<анонимный> source19:716019
<анонимный> source19:28789702
<анонимный> source19:716019
<анонимный> source19:13503522
<анонимный> source19:37260583
<анонимный> source19:6150450
<анонимный> source19:37121492
<анонимный> source19:6121223
<анонимный> source19:4357389
<анонимный> source19:3590845
<анонимный> source19:11161264
<анонимный> source19:839896
<анонимный> source19:716019
<анонимный> source19:23167365
<анонимный> source19:41458433
<анонимный> source19:5662026
<анонимный> source19:2980944
<анонимный> source19:43814798
button_cb http://127.0.0.1:6010/godot.loc/godot.editor.js:7
вот что на этого говорит дипсик
Этот вывод — не случайный сбой, а принципиальное ограничение веб-версии Godot. Ошибка ERR_CANT_CREATE в tcp_server.cpp означает, что Godot попытался открыть TCP-сервер (для отладки или языкового сервера), но браузер это запретил.
🎯 Почему это происходит именно в браузере
Ты запускаешь Godot не как обычную программу, а как веб-приложение (по адресу 127.0.0.1:6010). Браузеры из соображений безопасности не дают веб-страницам открывать «сырые» TCP-соединения или слушать порты .
Когда Godot запускается в браузере, он всё равно пытается поднять свои внутренние серверы (например, для отладки). Браузер блокирует это, и Godot выдаёт ошибку ERR_CANT_CREATE (не удалось создать) .
💡 Что это значит на практике
Это не значит, что ты что-то сломал. Это значит, что веб-версия Godot не поддерживает отладку и некоторые сетевые функции. В официальной документации прямо сказано: «Нет поддержки отладки. GDScript-отладка/профилирование... и другие функции, зависящие от протокола отладчика, не будут работать» .
Как это обойти:
Просто игнорируй эту ошибку. Она появляется в консоли браузера, но не мешает редактировать код, сохранять проект или запускать игру (нажатием F5). Если ты не пытаешься наладить сложную отладку с точками останова, она никак не влияет на работу.
Если же тебе критически важна отладка, придётся использовать нативную (десктопную) версию Godot, а не веб-версию.
так что это не баг а фича,не заморачивайтесь
там выдается такая ошибка
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE
может быть порт занят?Я хз вообще.Такое выводилось и в консоли ошибок годота.
вот полный вывод
ERROR: Condition "err != OK" is true. Returning: ERR_CANT_CREATE godot.editor.js:488:18
onPrintError http://127.0.0.1:6010/godot.loc/godot.editor.js:488
put_char http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
doWritev http://127.0.0.1:6010/godot.loc/godot.editor.js:7
_fd_write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
<анонимный> source19:25817979
<анонимный> source19:9497181
<анонимный> source19:6722534
<анонимный> source19:29047884
<анонимный> source19:3444469
<анонимный> source19:29048347
<анонимный> source19:29047607
<анонимный> source19:408029
<анонимный> source19:401610
<анонимный> source19:3441185
<анонимный> source19:41562155
<анонимный> source19:8875488
<анонимный> source19:8631484
<анонимный> source19:11706093
<анонимный> source19:40097321
<анонимный> source19:599776
<анонимный> source19:716019
<анонимный> source19:28789702
<анонимный> source19:716019
<анонимный> source19:13503522
<анонимный> source19:37260583
<анонимный> source19:6150450
<анонимный> source19:37121492
<анонимный> source19:6121223
<анонимный> source19:4357389
<анонимный> source19:3590845
<анонимный> source19:11161264
<анонимный> source19:839896
<анонимный> source19:716019
<анонимный> source19:23167365
<анонимный> source19:41458433
<анонимный> source19:5662026
<анонимный> source19:2980944
<анонимный> source19:43814798
button_cb http://127.0.0.1:6010/godot.loc/godot.editor.js:7
at: listen (core/io/tcp_server.cpp:57) godot.editor.js:488:18
onPrintError http://127.0.0.1:6010/godot.loc/godot.editor.js:488
put_char http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
doWritev http://127.0.0.1:6010/godot.loc/godot.editor.js:7
_fd_write http://127.0.0.1:6010/godot.loc/godot.editor.js:7
<анонимный> source19:25817979
<анонимный> source19:9497181
<анонимный> source19:6722534
<анонимный> source19:29047884
<анонимный> source19:3444469
<анонимный> source19:29048383
<анонимный> source19:29047607
<анонимный> source19:408029
<анонимный> source19:401610
<анонимный> source19:3441185
<анонимный> source19:41562155
<анонимный> source19:8875488
<анонимный> source19:8631484
<анонимный> source19:11706093
<анонимный> source19:40097321
<анонимный> source19:599776
<анонимный> source19:716019
<анонимный> source19:28789702
<анонимный> source19:716019
<анонимный> source19:13503522
<анонимный> source19:37260583
<анонимный> source19:6150450
<анонимный> source19:37121492
<анонимный> source19:6121223
<анонимный> source19:4357389
<анонимный> source19:3590845
<анонимный> source19:11161264
<анонимный> source19:839896
<анонимный> source19:716019
<анонимный> source19:23167365
<анонимный> source19:41458433
<анонимный> source19:5662026
<анонимный> source19:2980944
<анонимный> source19:43814798
button_cb http://127.0.0.1:6010/godot.loc/godot.editor.js:7
вот что на этого говорит дипсик
Этот вывод — не случайный сбой, а принципиальное ограничение веб-версии Godot. Ошибка ERR_CANT_CREATE в tcp_server.cpp означает, что Godot попытался открыть TCP-сервер (для отладки или языкового сервера), но браузер это запретил.
🎯 Почему это происходит именно в браузере
Ты запускаешь Godot не как обычную программу, а как веб-приложение (по адресу 127.0.0.1:6010). Браузеры из соображений безопасности не дают веб-страницам открывать «сырые» TCP-соединения или слушать порты .
Когда Godot запускается в браузере, он всё равно пытается поднять свои внутренние серверы (например, для отладки). Браузер блокирует это, и Godot выдаёт ошибку ERR_CANT_CREATE (не удалось создать) .
💡 Что это значит на практике
Это не значит, что ты что-то сломал. Это значит, что веб-версия Godot не поддерживает отладку и некоторые сетевые функции. В официальной документации прямо сказано: «Нет поддержки отладки. GDScript-отладка/профилирование... и другие функции, зависящие от протокола отладчика, не будут работать» .
Как это обойти:
Просто игнорируй эту ошибку. Она появляется в консоли браузера, но не мешает редактировать код, сохранять проект или запускать игру (нажатием F5). Если ты не пытаешься наладить сложную отладку с точками останова, она никак не влияет на работу.
Если же тебе критически важна отладка, придётся использовать нативную (десктопную) версию Godot, а не веб-версию.
так что это не баг а фича,не заморачивайтесь
А прикиньте навайбкодить Годот.. так, мысли вслух
>1) Скульптинг в Terrain3d
>3) Экспорт в Blender
>7) В годоте коллизию делаю Trimesh
Нафига тебе "скульптинг" плоского ландшафта в "height map" плагине для Godot, если ты планируешь всё равно дорабатывать в Blender и импортировать результат с генерацией тримеша (а не height map, который обычно для такого нужен)? Скульптинг в Blender намного более продвинутый и позволит сделать куда более оптимальные меши совершенно любой формы (любые нависающие скалы, пещеры, мосты, летающие острова и прочее на твой вкус). Лучше начинай сразу с Blender - тогда тебе не потребуется никакой плагин (но есть нюанс, см. ниже).
>8) Закидываю все в одну сцену
>9) Запекаю свет и тени
>Подводные?
Поскольку ты запариваешься с оптимизацией графики (запекание света и тени), ты, видимо, ориентируешься на слабые устройства (старые ПК, мобилки, браузер). Но твоё "закину в одну сцену целую кучу trimesh" говорит о том, что ты планируешь держать в RAM большую локацию с самой тяжёлой физической моделью. Конечно, всё зависит от детализации мешей и их количества, но это не самый оптимальный подход. Оптимальнее было бы использовать HeightMapShape3D для физики и какой-то способ уменьшить детализацию ландшафта. Хотя...
>Регионы в Terrain3d = 64 на 64, vertex spacing = 2.0.
>Планируется от 2 до 6 регионов на сцену.
Я правильно понял, что у тебя квадраты 128 на 128 метров, и суммарно площадь около 256 на 384 метра? Как-то маловато, не думаешь? И уровень детализации в 2 метра подходит только если у тебя камера находится очень далеко от ландшафта, но тогда размер 256x384 вообще ни на что не годится. Впрочем, я этот плагин давно не пробовал и не знаю, правильно ли я интерпретирую эти значения. Да и про что твоя игра? Типа RTS/TBS?
В целом, я бы сделал одно из двух: либо делать всё в Blender, либо написать свой собственный редактор карт, который позволяет делать всё внутри Godot/внутри самой игры, не полагаясь на сторонние плагины. Так будет надёжнее, чем полагаться на какой-то плагин, который приходится допиливать напильником на коленке.
>Godot 4.5
Почему не актуальная версия? Если ради совместимости со старым железом, то лучше выбирать между 4.4.1 и 3.6.3; поскольку в версиях после 4.4.1 требуется поддержка SSE4.2 (она есть не у всех, кто мог бы спокойно играть в игру на Godot), а во всех 4.x версиях не очень хорошая версия Compatibility (OpenGL ES3), если сравнивать с тем, что было в Godot 3.x (ES2/ES3). Но старого железа всё меньше в обиходе, так что, если ты не беспокоишься о совместимости с каким-то конкретным личным девайсом, рациональнее брать актуальную (4.8).
А-а-а-ах, добавил J U I C Y анимации стандартному интерфейсу и реализовал подробный редактор пиксельного персонажа с разными расами в пока что отсутствующую игру. Наша школа! Молодец! Два сока тебе. Продолжай - у тебя всё получится!
>>1112339
>кнопки пытаются убежать
А ты глупенький и ничего не понимаешь. И игра твоя скучная будет. Бе.
>>1112346
>Добавляет игре детскости и простоты.
Так говоришь, будто это что-то плохое. Предпочитаешь dark and gritty?
>когда узнал, что matcap - это просто картинка
А про навмеш что скажешь? Его отдельно изменять в рантайме или есть обходные пути, чтобы юниты друг друга обходили? Типа отловить столкновение и перебрать всех юнитов для того, чтобы их обойти, обсчитав отдельно путь.
>чтобы юниты друг друга обходили
Там нужно галочку NavigationAgent2D.avoidance_enabled поставить и ещё какой-то обработчик - почитай документацию:
https://docs.godotengine.org/en/stable/tutorials/navigation/navigation_using_navigationagents.html#navigationagent-avoidance
Но нужно сначала задуматься, ту ли игру ты делаешь? Как я понимаю, навигация на навмешах лучше всего подходит для динамичных игр типа top-down шутеров/гоночек. Если у тебя ближе к рогалику/JRPG, то не факт, что навмеши тебе нужны. Если что-то ближе к "vampire survivors", то там нужна совсем другая система... В общем, не нужно воспринимать "navigation server" как единственное и гарантированное решение любой проблемы с "навигацией" в играх.
>гоночек
А, не, там тоже какая-то другая система. По-хорошему, синглплеерные гонки - это вообще фейк, аттракцион на рельсах. Машинки не "ищут путь", а двигаются вдоль линии, ускоряясь и замедляясь в зависимости от действий игрока, чтобы игроку не одиноко было и казалось, будто он вот-вот выиграет или проиграет. И если это что-то вроде GTA 1/2, то там система посложнее простого навмеша. В общем, думать надо много, независимо от типа игры...
Честно, не представляю даже, где можно использовать ванильный навмеш и ничего не менять... шутеры?
Это на случай если я придумаю нормальный язык программирования, который будет сочитать в себе:
- простоту стейтмашины
- простоту работы с множествами
- возможность сохранять переменные
Поэтому движение по навмешу симпловое.
> я придумаю нормальный язык программирования
Буквально последние месяцы, когда ещё есть смысл что-то кодить, буквально программирование порешали, по заверениям западных кодеров. Поздно выдумывать новые языки. Просто задаёшь промт нейронке, пару раз корректируешь, и получаешь готовый модуль.
Надо было учиться рисовать.
Арт игроки быстро выкупают нейрослопный, в отличие от нейрослопного кода, который рядовые выкупатели не выкупят, поэтому кодеры соснуле, не разгибаясь.
Буквально через год нейрослопный арт сравнится по качеству с натуральным - и всё, блять. Кнопка "зделать зоебись" материализуется в твоей реальности перед твоими глазами.
Если тебе нужна 2D среда для симуляции движений NPC, описанных через код, написанный игроком, тогда тебе стоит начать не с навмеша, а с примитивного клеточного пошагового мира, в котором можно делать простые шаги: "шаг вверх", "шаг вправо", "шаг вниз", "шаг влево"; либо движение в стиле танка: "прямо", "поворот налево (90)", "поворот направо (90)", "назад". В качестве базовых задач для NPC, вместо "сражений в данже" лучше начать с простого, вроде: "открыть дверь", "открыть ящик", "закрасить клетку", "проверить цвет клетки", "проверить стену" и т.п. Подобного рода мини-игры можно назвать базовым стандартом игр про программирование. Типичной целью игрока является написать минимум кода для достижения какой-то задачи (чаще игроку даются фишки-кнопки, т.е. визуальный язык вместо обычного текстового). Если сможешь реализовать что-то подобное, тогда будешь задумываться о чём-то более сложном.
Прежде, чем изобретать свой язык программирования, лучше освой несколько существующих и научись писать сложные программы вручную, без помощи LLM. Если всё же хочешь поскорее "изобрести язык", то посмотри в сторону FORTH и в целом "стековых языков" - их разработать чрезвычайно просто на любом языке даже новичку, потому что базовый концепт очень прост.
>>1112091
Ну, тут есть несколько вариантов решения проблемы:
1. Парсить код игрока вручную, обрабатывая ошибки по-своему. Это наилучший вариант, если ты делаешь тренировочную игру для обучения, поскольку встроенный парсер не предназначен для обучения. Для примера, стоит посмотреть код https://github.com/GDQuest/learn-gdscript
2. Открыть исходники движка, предоставить доступ к парсеру и сделать кастомную сборку. Это наилучший вариант, если тебе нужен полный и надёжный контроль над встроенным парсером.
3. Открыть журнал (godot.log) и распарсить его, чтобы вывести ошибки на экран. См. пикрил.
Нюансы:
- журнал ошибок точно создаётся на ПК, но только если юзер не запустил игру из консоли;
- сомневаюсь, что этот файл создаётся на смартфонах, тем более его нет в веб-браузере;
- там могут быть непредвиденные строки, которые "сломают" извлекающий ошибки код;
- код на скриншоте будет очень медленным, если в журнале накопилось много записей;
- удалять/очищать файл журнала нельзя, иначе он почему-то перестанет заполняться;
- ошибки могут быть непонятны для игроков - они предназначены для разработчиков.
Но в целом, для прототипа игры, решение неплохое. На синей изоленте держится.
>>1112601
>Буквально последние месяцы, когда ещё есть смысл что-то рисовать красками на холсте, буквально краски порешали, по заверениям западных фотографов. Поздно выдумывать новые кисточки. Просто наводишь фотоаппарат, пару раз щёлкаешь, и получаешь готовую картину.
>>1112603
>Буквально через год фотографический арт сравнится по качеству с натуральным - и всё. Кнопка "сделать фото" материализуется в твоей реальности перед твоими глазами.
Какие-то слабые у вас аргументы, жирноватые. Нужно тоньше троллить, например:
>Буквально через год роботы вылезут из серверной и начнут насиловать кожаных мешков. Даже если вы говорили "спасибо" чатботам, вас уже никто и ничто не спасёт. Превратитесь в кожаную сферу без рта и будете хотеть кричать, но не сможете. Поздно хвататься за оружие - владельцы серверных сами давно вооружились и ждут нападений поехавших. Никакими деньгами от роботов не откупитесь, ничего им не надо, кроме того, чтобы вы хотели кричать без рта. Так сказали какие-то учёные из фан-клуба какого-то авторитетного параноика, который ещё фанфик писал про магию.
> Какие-то слабые у вас аргументы, жирноватые. Нужно тоньше троллить, например:
Как же ты трясёшься.
>Как же ты трясёшься.
Анон, мы сейчас на форуме. Ты текст перед глазами видишь, а не другого человека. Если у тебя перед глазами трясётся текст - это не человек, написавший текст, трясётся, а тебя самого трясёт. Вопрос только, почему? Пьян?
Если серьёзно, как меня это всё может касаться? Я не какой-то там профессионал, а обыкновенный хикикомори.
По делу есть что сказать, или просто поговорить не с кем?
Почему ты сюда свои промпты отправляешь, а не чатботу?
А вы, собственно, почему интересуетесь? Вы не из милиции случайно?
>во всех 4.x версиях не очень хорошая версия Compatibility (OpenGL ES3), если сравнивать с тем, что было в Godot 3.x (ES2/ES3)
В каких случаях (кроме веба?) может понадобиться именно Compatibility рендерер настолько, чтобы юзать годот 3.х?
мимо
>может понадобиться именно Compatibility рендерер настолько, чтобы юзать годот 3.х?
У меня пока только один случай был, и то давно, не проверял больше: Polygon2D, натянутый на Skeleton2D, в Compatibility режиме Godot 4.x не отображался на моём смартфоне, а Forward Mobile показался слишком прожорливым для простой 2D игрушки с анимацией (судя по датчикам самого смартфона), поэтому пришлось попробовать Godot 3.x и там этого бага не было. В issues этот баг описан давно, но никаких движений замечено не было. Касается старых смартфонов (Android 11). Поскольку Godot 3.x работает нормально, дело, скорее всего, в реализации рендерера 4.x, но это касается лишь только какой-то специфической версии драйверов старых смартфонов, поэтому вряд ли этот баг когда-либо исправят.
Это случай из разряда "хотел использовать старый смартфон как цифровую фоторамку, а новая версия движка глючит".
Снег тоже будет, но ближе к горам а вообще хотелось бы смену времен года, но пока не в приоритете, поэтому хз. А так пока не добавляю тк хочу чтобы он преломлялся под персонажами и оставлял следы, а это муторно и не хочу пока думать
> не хочу пока думать
Это уже не обязательно. Клод за тебя подумает, сделает игру, заработает бабки и потратит на шлюх и водку
>Буквально последние месяцы, когда ещё есть смысл что-то кодить,
Особенно на фоне обращения корейского президента и обвалом ИИ рынка на следующей день.
Ждуля, нельзя на каждое сообщение отвечать - что скоро все и можно вообще больше уроки не делать.
>только иногда самому нужно будет прыгать в локи,
Выглядит ужасно и запутанно. Почему нельзя сделать проще. Вы же все геймеры и должны чувствовать геймдизайн на уровне ДНК.
>я придумаю нормальный язык программировани
Насколько вайбкоди оторванны от реальности.
Почему запутанно, в каком плане? Типа выбираться из уровня? Ну переходы стоят с четырёх сторон, можно просто идти по прямой сквозь деревья и кусты и выйти из них. А ресурсы спавнятся перед лицом в зависимости от характеристики выживания, их находит не игрок, а персонаж по сути
Я принимаю этот мир и его правила и его графику и все остальное. Меня интересует два вопроса:
1. В чем армагедон? Почему в мире нет людей и я выживаю с оружием и от какой экзистенциальной угрозы я бегу.
2. Зачем мне исследовать локи? Ну просто, почему я не могу остаться в одной логе на все время?
Ты выходишь за локу, оказываешься в режиме карты, что-то там двигаешься (то есть там есть какой-то геймплей), нужно на карте дойти до другой локи. Это вообще неинтуитивная штука, какая-то избыточная миниигра между локами, зачем она?
Если карта не ориентир, а часть геймплея, сделай автоматическую анимацию - типа ты вышел и пока идет загрузка рисуется пунктир из локи "А" в локу "B".
>Вы же все геймеры и должны чувствовать геймдизайн на уровне ДНК.
Корреляция слаба. Это как ожидать что любитель почитать с наскока напишет нормальную собственную книгу. Потребление с майндсетом потребителя сильно отличается от потребления с майндсетом создателя. Первые играют/читают не вдумываясь, вторые разбирают, вникают и анализируют.
>Распиши
За щекой.
Ладно, покормлю вайбкодю, простите.
Если собрать "движок" из разных либ - это еще реальная задача, то написать и отладить свой язык будучи ньюфагом, это рокет сайнс.
1. Ну, игра ещё разрабатывается, люди будут, и мирные поселения, и сюжет, начинаться все будет в одной из них, и оттуда уже будет строиться сюжет. А-ля наша деревня умирает, найди косогор. Я пока прост не занимался нпс бандиты каннибалы, мутанты, вооружённые спец отряды. Потом покажу как начну делать. Армагедон кароч будет заключаться в смещении орбиты и вращения земли, что повлекло изменения климата и размножения биологических гадостей. В следствии войны построили гигантские двигатели в земле, и запустили их на минуту в ходе атаки других стран, но все пошло наперекосяк...
2. Можно остаться и выживать в одной точке. Но я кароч что хочу вплане стимула сделать, подумываю часто, это условно бесконечный фарм снаряги грубо говороя, не буквально бесконечно, типа как в бордерлендс искать пушки и менять, чтобы идти в более опасные зоны. Но я пока ещё думаю это все.
>>1112664
Ну мир исследовать. Бродить по глобал мапе и искать лабы, чтобы лутаться, либо по сюжету через опасные зоны проходить. Это грубо говоря фасттревел, но без моментальной загрузки, чтобы не бродить долго, а только до точек интереса, или обходя опасные участки. Плюс через глобальную карту можно добавить случайные встречи. Насчёт интуитивности хз, мне кажется нормально, игроки играют и в гораздо более сложные игры
>Бродить по глобал мапе и искать лабы, чтобы лутаться
Тогда карта должна быть сеткой, а места возможного интереса помечаться каким-то знаком (вопросами как на пикче).
Но ведь дешевые токены почти все... У ИИ хоббийного/инди применения не будет из-за цен на токены, локалки на обычных видюхах кодинг не потянут, ИИ останется только для корпораций с огромными продажами.
>Можно остаться и выживать в одной точке
Всмысле оставить перса и пойти пить чай? Не, я к тому что либо твари должны лезть по экспоненте, когда уже даже лут собрать не успеваешь, либо выбросы как в зоне, но самое логичное - это транспорт который тебя вечно ждать не будет. Потому что без транспорта ебошить через всю страну пешком это выглядит странно.
>бесконечный фарм снаряги
Зачем? Это дилемма над которой я тоже голову ломал очень долго. Есть три пути: посмотреть сюжет/квесты/титры, сделать забег по рогалику со сбром уникальных айтемов, сделать забег на рекорд с бесконечным режимом. В первом случае нужно прописывать много диалогов и сюжета, во втором добавить в игру сотни уникальных вещей, а в третьем сделать кор геймплей настолько залипательным чтобы игрок на 12 часов провалился и не заметил.
По факту соло разрабу доступен только второй вариант. Придется повозиться с добавлением предметов/пушек/апгрейдов/модификаторов/аммо + биохакинг какой-нибудь. Но зато да, все остальное складывается в единое целое: носись по локам, фармь предметы пока не сдохнешь. А потом по новой.
> Армагедон кароч будет заключаться в смещении орбиты и вращения земли, что повлекло изменения климата и размножения биологических гадостей
Первое что ты должен сделать - это передать погружение своей идеи. Не важно что там повернулась ось или вселенная вывернулась наоборот - я не чувствую погружения. Кроме, может, советской карты, но это же не проблески сталкера, да?
> бесконечный фарм снаряги
Самая трудная часть геймдизайна - это завуалировать цикличные процессы, чтобы мозг не успел понять обманку.
Расскажешь как сделал бесконечный фарм снаряги.
Ладно, все равно тут о проблемах геймдизайна не поговорить, о чем я вообще.
>Всмысле оставить перса и пойти пить чай?
Нене, я имел ввиду что я же считай делаю этакий выживастик, а значит нужно будет добывать ресурсы. Ну и тип при желании можно просто остаться в точке аутировать, а если понравились ресы, подземелья и сама лока, можно будет вернуться в неё по тем же координатам, и заново залутать.
По поводу выброса кста. Я ща кароч смотрю созданный в бездне, и чёт прям загорелся идеями всяких мутаций, и вот думаю что окружение должно периодически заражать гг, и мутировать в зависимости от зоны. Типа ешь местное мясо, получаешь периодический дамаг, и рисуем на 2д аватаре какие нибудь язвы, но потом можешь спокойно питаться здесь. Но хз, щас чёт так задумался и расписал, и показалось что это ток на словах может быть интересно, кароя ещё думать буду
он вообще собирается этот уебушный пейнторожденный логотип менять? он вообще в курсе что только по этой причине проигрывает юнити. Только по этой
Расскажи на примере как завуалировать цикличный процесс.
Как сделать так, чтобы слой где всякие декорации типа там книг, рисовались поверх предметов с нижнего слоя типа столов, полок, но при этом когда игрок к ним подходил, они его не перекрывали?
Я делаю как годот подсказка говорит, и ставлю ориджин y sort ниже так, чтобы предметы отображались, как будто они располагаются ниже предметов на которых они лежат, но из-за этого они перекрывают игрока тоже.
Нейронка вообще говорит, что нужно поменять z index, но тогда эти предметы будут всегда поверх игрока?? Короче я не знаю, что делаю, помогите пожалуйста
Это душа, бездушный ты корпорат ебаный-вылизанный, хртьфу.
Так как теоретически если учиться с нуля то выдать готовый продукт можно будет только лет через 5. А к тому моменту наверное уже по кнопке сделают возможность генерить себе любую игру.
Или все же все не настолько пессимистично?
Штатные языкосрачеры на месте? Объясняйте, почему:
>@onready var _bla_bla := $BlaBlaBlavich as BlaBlaBlavna
НАСТОЛЬКО анти-паттерн, что в 4.8 теперь пикрил?
У меня из-за этого 100500 предупреждений...
А ведь так хорошо раньше было...
моржами пользоваться нельзя потому что, тебя любая нейронка сразу предупредит, но ты же самый умный
>>1112702
абсолютно никаких подводных, вкатывайся смело
>Снег ... [сминался?] под персонажами и оставлял следы
О, я видел пост с объяснением принципа на Reddit, кажется, аж несколько лет назад. Принцип на удивление прост: тебе нужна большая текстура типа "height map", которая определяет степень "смятия снега", и используется в шейдере снежной поверхности; данная текстура обновляется с помощью SubViewport или недавно добавленного класса DrawableTexture. Нюанс в том, что каждый объект, который должен мять снег, должен иметь свой личный датчик пола, определять тип пола и отправлять ему команду на смятие; при этом размер текстуры и необходимая плотность сетки ограничивают эту фичу ресурсами целевого компа (грубо говоря, маленькую лужайку - норм, большую поляну - сложнее сделать)... Впрочем, ты прав, что откладываешь эту фичу на потом.
>>1112636
Ты молодец, но... Хоть я и видел множество похожих игр в 2D, но у меня впечатление, что в 3D данная механика не очень смотрится: она принудительно "вырывает" игрока из "потока"... Я бы попробовал сделать вместо "3D портала" обычную карту, доставаемую снизу экрана анимацией, а лучше вообще как 3D объект в руках героя, позволяющую запустить "fast travel" из любой точки локации (пока рядом нет агрессивных противников), без необходимости топать до края карты. А если игрок всё-таки топает до края карты, то с края карты он попадает на следующую карту, которая физически соседствует с предыдущей. Т.е. это как бы "open world с экранами загрузки и опциональным fast travel", а не то, что ты сделал (что-то вроде "overworld" из JRPG). Второй вариант: вместо плоской 2D карты сделать лоупольную 3D карту а-ля Google Earth, на которую камера "отдаляется", "вылетая из игрока", как в GTA 5. Но это будет сложнее реализовать.
В общем, нужно как-то сгладить переход между 3D геймплеем и 2D геймплеем. Чтоб это не было принудительным "рывком", а хотя бы плавная анимация (камера отдаляется далеко в небо), а лучше - осознанное действие игрока (нажатие кнопки открытия карты). Принудительный рывок нормально работает в 2D играх, потому что там разницы между двумя картами особо нет - что то 2D, что это 2D, геймплей практически один и тот же, разница только в масштабе тайлов карты.
>>1112656
>Выглядит ужасно и запутанно.
Это классика, это знать надо, это БАЗА геймдева прошлого века.
>>1112664
>какая-то избыточная миниигра между локами, зачем она?
Так геймдизайнеры в прошлом делали "большие" миры, состоящие из "маленьких" комнат. На сегодняшний день эта механика используется только из-за ностальгии, а в прошлом она была вынужденной из-за технической ограниченности игровых приставок и компьютеров тех лет.
>>1112675
>В первом случае нужно прописывать много диалогов и сюжета
Не обязательно писать много текста - бывают нарративные игры с минимумом текста...
>во втором добавить в игру сотни уникальных вещей
Суть рогалика не в сборе коллекции из 999 "уникальных" пистолетов, отличающихся оттенком ручки и одинаково бесполезных после получения первого автомата, а в том, что там в каждом забеге может попасться что-то непонятное, что заставляет думать головой, а не тупо открывать каждый ящик на пути. То есть интересный рогалик может быть с минимумом контента, а когда разработчик добавляет 100500 "уникальных вещей" в рогалик - это от слабости геймдизайнера.
>а в третьем сделать кор геймплей настолько залипательным чтобы игрок на 12 часов провалился и не заметил.
А у тебя нет другого пути. Либо ты делаешь залипательный геймплей, либо никакой сюжет и никакие тысячи предметов не удержат игрока в твоей игре. Потому что сюжет можно посмотреть в летсплеях или прочитать на фанатской вики (как только игра наберёт сотню-другую игроков), а тысячи предметов - это просто бесполезные пиксели без увлекательного геймплея. Поэтому ты должен сначала сделать геймплей, который хорош сам по себе, а уже потом навешивать на него 100500 разных предметов и квестов про убийство волков ради получения крутой шмотки.
>>1112682
>мутировать в зависимости от зоны
>показалось что это ток на словах может быть интересно
Нормальная тема, видел в Elin. Правда, не знаю, как оно будет без сейв-скама, я себе только положительные мутации насейвскамил, лол. Так что мой совет: добавь каких-то относительно дешёвых лекарств, позволяющих контролировать и управлять мутациями героя. Например, если игрок обнаружил, что на поляне его конечности удлиняются, он может использовать эту мутацию, чтобы карабкаться по скалам, но ему потребуется лекарство, если он захочет спуститься в узкие пещеры... или можно сделать "анти-мутации", когда нахождение в какой-то зоне сокращает длину конечностей, фактически отменяя предыдущую мутацию удлинения. Так игрок будет чувствовать, что мир опасен (может наложить проблемные эффекты), но сохранять контроль над процессом - может вернуть вспять негативные эффекты без сейвскама и потом найти позитивные эффекты.
Вообще, я бы работал над тем, чтобы у игрока не возникало желания сейвскамить (или юзать CheatEngine для накрутки каких-то значений, или юзать какие-то "читерские" модификации). Кажется, это называют "pain points" - элементы игры, вызывающие только боль и страдания без реального удовольствия игрока. Игроку нужно испытание, но справедливое; нужен стресс, но оправданный. Если игра только навешивает дебаффы, игрок прибегает к сейвскаму/читам, и окончательно убивает свой интерес к игре...
>смысл ради этого бросать работу
У тебя есть возможность жить лет эдак 10 без работы, и при этом не стать бомжом? К примеру, богатые и любящие родственники, лишняя квартира для сдачи в аренду, огромное состояние на вкладах в банке? Тогда никакой проблемы нет. Но если ты едва сводишь концы с концами и рассчитываешь, что вот если сейчас взяться за геймдев, то через N времени обязательно выйдешь на какой-то доход - тогда лучше не бросай работу, потому что дохода либо не будет, либо он будет смехотворным и не покроет расходов. Либо ты пойдёшь на галеру за зарплату - штамповать бездушные помои, но чем это отличается от твоей текущей работы, какой бы она ни была? Это такой же физически напряжённый, неблагодарный труд...
>ебашить целыми сутками обучения
Обучение так не работает. От 24/7/365 обучения пользы меньше, чем от обучения 2 часа вечером по будням. Мозгу необходимы периоды отдыха для закрепления усвоенного. В худшем случае ты просто выгоришь, деморализуешься и забросишь это начинание, даже не распробовав толком.
>поезд уехал и нейронки уже все что угодно сделают
>по кнопке сделают возможность генерить себе любую игру
"Поезд уезжает" только у мелких кабанов, у которых галера мелковата, и поэтому они сейчас отчаянно дерутся за место под солнцем Гугла, Стима и прочих. Но это - кабаны, они всегда делают бездушные помои - с нейронками или без - они никогда не занимались искусством, а только увеличивали объём цифрового мусора в интернете. Поэтому для реальных творцов от нейронок ничего не поменялось; скорее, наоборот, ситуация только улучшается - кабанам дали патефон, чтобы они крутили ручку и развлекали тупое быдло, которому плевать, что потреблять, пока настоящие творцы остаются в своих элитных творческих кругах, до которых кабанам вообще нет дела.
Если тебя беспокоят нейронки, вспомни любые прежние технологии массовой репродукции контента: фотография не убила изобразительное искусство, а только вытеснила с рынка кабанов, единственная работа которых была в создании портретов за деньги; звукозапись не убила музыку и песни, а только вытеснила кабанов, исполнявших песни и музыку за деньги; кино не убило театр, а только вытеснило кабанов, кривлявшихся за деньги. При этом не всякий владелец фотоаппарата может создать реально художественную фотографию - нажать кнопку могут все, но выбрать цель и условия нужно уметь. Но для тебя представляет даже лучшая фотография, если ты не знаешь, кто и зачем её снял? Что для тебя даже лучшая картина в мире, если ты не знаешь, кто и зачем её создал? Это просто шум, какие-то фотоны, раздражающие колбочки сетчатки твоего глаза. В них не больше смысла, чем в том, что ты видишь за окном или у себя под ногами. Для искусства не достаточно "продукта потребления" - нужен создатель, который приложил к своему созданию свои руки, мысли, чувства, знания и опыт. Поэтому продукция кабанов - это всегда какие-то помои, как будто они взяли фотоаппарат и сделали миллион снимков в надежде, что хоть один из них удастся продать дороже плёнки; сделали миллион портретов, в надежде, что хоть один клиент будет доволен и оплатит стоимость всех красок и холстов. Им нет дела до того, что они делают, а их клиентам нет дела до них самих, поэтому это никогда не будет проблемой для тех, кого реально интересует искусство и занятие искусством.
Другое дело, что пока что тебе нужно иметь стабильный источник дохода, чтобы заниматься искусством... Но в этом как раз могут помочь ИИ и робототехника - капитализм уже трещит по швам и удерживается искусственно, и с введением полностью автоматических производств всего, что только можно произвести, старая система рухнет окончательно. Тогда у всех будет куча свободного времени на искусство и развлечения без необходимости добывать деньги на пропитание.
Так что не нужно бояться, но и не стоит бросать свой единственный источник стабильного дохода.
>бывают нарративные игры с минимумом текста
Там весь текст нарисовали в виде левелов. А это еще труднее. Это вообще довольно трудно, сочинять что-то интересное. Можно тыкнуть на инди хит, а вот самому сделать...
>рогалик может быть с минимумом контента
Нет, не может. Два рана с одними и теми же шмотками = смерть рогалика. Экспериментально вычислили что минимум должно быть 150 уник айтемов. И даже это спустя пару месяцев игры приедается.
>Либо ты делаешь залипательный геймплей, либо никакой сюжет и никакие тысячи предметов
Хорошо когда все вместе, но это явно не про шутер. Залипательность это больше про визуал, подачу, эффекты, звуки, азарт. Вот три в ряд залипательные, а брожение по пустошам нет. Просто не тот жанр для такого.
>А если игрок всё-таки топает до края карты, то с края карты он попадает на следующую карту, которая физически соседствует с предыдущей. Т.е. это как бы "open world с экранами загрузки и опциональным fast travel", а не то, что ты сделал (что-то вроде "overworld" из JRPG).
Ля кста интересная мысль, записал себе на доску. Только тогда действительно придется сетчатую карту сделать, и увеличить их размер, чтобы такое передвижение имело смысл, тк щас по сути карта генерируется по int x,y координатам.
>Так что мой совет: добавь каких-то относительно дешёвых лекарств, позволяющих контролировать и управлять мутациями героя
>когда нахождение в какой-то зоне сокращает длину конечностей, фактически отменяя предыдущую мутацию удлинения
Вот да, у меня примерно такие мысли по поводу мутаций и условного их контроля. Щас пришла кста такая мысль, помню играл в третий вейстленд, длс, и там на персонажах радиация накапливалась, а затем ролила разные мутации, и вот щас думаю, можно действительно заставлять гг копить на себе различные бактерии, которые затем в зависимости от стадии будут ролить нам мутации, иногда заменяя их, а от самих бактерий можно было бы избавляться в сейфзонах либо на месте сыворотку изготавливать, так сказать смывая с себя грязь после потного дня и останавливая роллинг.
По поводу сейвскама, хз, как ты и сказал по хорошему нужно работать над тем чтобы не возникало желание сейвскамить, согласен, но это всё индивидуально, тут скорее нужно думать хочет ли игрок впринципе мутировать и что-то там получать, и если он согласен, то просто примет правила игры, а перезагрузиться только чтобы сохранить желание продолжать. Посмотрим кароч, да
да просто сделай сейф при выходе и при каждом событии, а после смерти возрождай в хабе. Загрузки из сохранок это такой анахронизм что я ебал того маму рот
Чтобы пользователь тебя выследил и по башке арматурой постучал, потому что не смог загрузится из твоего автосейва после 10 часов в игре..
>Расскажи на примере как завуалировать цикличный процесс.
Из базового
Тиры - оружия с прогрессией, где 5 тир к лейт гейму.
Сложный расчет где трудно в голове целыми числами быстро посчитать что-то (не важно что это, от боевки до крафта).
Итд.
>Как сделать так, чтобы слой где всякие декорации типа там книг, рисовались поверх предметов с нижнего слоя типа столов, полок, но при этом когда игрок к ним подходил, они его не перекрывали?
Сделай area у книги или у игрока и когда происходи событие выхода/выхода меняй кодом z-index.
>Есть ли смысл ради этого бросать работу и
Давно не было лудоманов алыншиков.
>@onready var _bla_bla := $BlaBlaBlavich as BlaBlaBlavna
Не понял о чем ты
В обычных статичных языках
Разница между колоссальная.
@onready var _bla_bla := $BlaBlaBlavich as BlaBlaBlavna // ранйтам
@onready var _bla_bla : BlaBlaBlavna = $BlaBlaBlavich // комплтайм
У гдскрипта типизация для галочки (будут это отрицать, но посмотри сорцы годота), поэтому типизация скорее для автокомплита в редакторе.
>Это классика, это знать надо
Ты не понял о чем я.
>БАЗА геймдева прошлого века.
Чел я лично играл 1-2 дум, варкрафты, херетик и прочее. Причем скажу что второй варкратф тормозил на 386 машине (на 486 норм уже было, а вот пентиум - ну ты понимаешь, пентиум!).
Я понял что он хотел сделать, но получилась какая-то шляпа.
Типизация гдскрипта ускоряет рантайм. Будешь это отрицать - посмотри сорцы.
>Типизация гдскрипта ускоряет рантайм
Тесты ты не покажешь, кроме той буллшит статьи, в которую ты поверил на слово, как истинный фанбой?
Там есть оптимизации в сравнение с обычным Variant, но это не значит var a: int - становится нативным int - это просто хинт, подсказка для некоторой оптимизации. Но интерпретация байткода сделана настолько плохо, что это все вообще не имеет значения (там даже не уровень питона или руби).
Манерв не засчитан. Следуй своему совету и ныряй в сорцы. Пока вижу у тебя только манятеории, спекуляции и догадки.
>Манерв не засчитан
Так это я предложил посмотреть сорцы. Ты используешь мой аргумент против меня. Это демагогия уровня начальной школы ("сам такой")
>Сорцы
Так ты открываешь их и видишь что там все так же на вариантах.
>манятеории, спекуляции и догадки.
Ну и в отличие от тебя я тестил - результат на уровне нефига.
Ты же тупенький озлобленный вахтерышка, если я сейчас снова полезу в сорцы, потрачу снова время на реверс, и принесу пруфы ты начнешь жать кнопку жалобы. Мы же уже это проходили, все неудобное тебе удаляется.
>>1112707
>>1112713
>>1112736
Короче я понял что нифига не понял. Есть два мнения: Ты дебил оно тебя сожрет и Искусство никогда не умрет.
Но я просто заебался так жить без перспектив, а в геймдеве если попробую то я хотя бы буду в среде которая хоть немного мне нравится. И вопрос был в том смогу ли я свою копейку на еду заработать, вложившись примерно в пять лет своего усиленного оубчения. Или уже нейронки отберут к тому моменту хоть какую-то надежду на тарелку макарон с сосисками?
>И вопрос был в том смогу ли я свою копейку на еду заработать, вложившись примерно в пять лет своего усиленного оубчения.
Смехуечки в сторону - не сможешь. Даже ДО нейронок тут реально зарабатывали единицы индюков, и чет около 80% стимо релизов не имели даже 10 ревью. А до стима еще доползти надо, а там еще санкции-хуянкции. А в современном слопоапокалипсисе "игр" скоро станет больше чем игроков, и без ревью будут оставаться 98% релизов.
Если ты хочешь делать для души - смысл имеется, если твоя душа в силах переварить современные ИИшные реалии (при этом ты должен иметь другой доход, либо у мамки на шее сидеть).
Если как заработок - однозначно нет.
Вообще непонятен твой взгляд на это.
Да, нейронки уже сделают по кнопке что угодно, а не через год.
Как это мешает вкатываться в геймдев?
Единственное что нейронки не сделают - это не скажут тебе, что нужно делать.
Если у тебя есть гениальные идеи, то просто делай за месяц качественный прототип, бери издателя/краудфандинг, наслаждайся.
Если ты хочешь исполнять чужие идеи - перспективнее курьера во Вкусвилле вряд ли сейчас найдешь что-то.
>а в геймдеве если попробую то я хотя бы буду в среде которая хоть немного мне нравится
Делать игры это не тоже самое что играть в игры. Сначала попробуй чтобы понять что это такое.
Алын ставят только лудики. И тролли
>Чтобы работало на 0.000000005 наносек быстрее?
С чего ты взял что это будет быстрее? Как вы вообще умудряетесь что-то утверждать не потестировав?
Дерево сцен вероятнее строиться за один проход на плюсах при инициализации, а в твоем примере ты же дергаешь апи каждый раз и каждый раз пересобираешь часть (или все) дерево.
Ну и во вторых вызовы на опкоде гдскрипта это всегда дорого. Придумывать там абстракции не нужно. Чем чище будешь дергать АПИ тем быстрее будет.
Легко говорить. Видел это?
Промпт в ДЖВА коротких предложения склонировал нетривиальную игру.
Геймдев превратился в ютуб, где каждый школьник может насерить тонну видосов на тонну каналов одновременно с помощью нейронок
https://youtu.be/J4LeOYrKEhE
во-первых, нахуя засорять редактор, профи им вообще не пользуются, во-вторых вайбкоденг
Это не нетривиальная игра. Просто отполированная. Такое по идее на каком-нибудь raylib можно написать и выпускать почти сразу, не нужно демку открытой 6 месяцев держать.
Не могу. Я понял, что мне неинтересно играть в игру, в которой я заранее знаю каждый пиксель. В играх из-под нейронки хоть какой-то элемент неожиданности есть, жду пока прокачаются настолько чтобы не чистить за ними вилкой, спойлеря себе весь контент. Я знаю про процедурные миры, но мой взгляд чистая (а иначе неинтересно, потому что нет элемента неожиданности - все проспойлерил еще во время отладки и настройки) процедурка подходит больше для технодемок чем для поиграть с удовольствием.
>Игры делайте
~20%
Нужно немного отдохнуть, пофлудить, поиграть для вдохновения.
>делай рогалики с рандомом, как все
Сейчас бы тролля-вайбкодю, у которого нет личной жизни и он постит за десятерых в каждом треде двача - уговаривать делать игры.
>Как ты узнал что я сегодня тоже отдыхаю?
Я про тебя и не говорил.
>тоже отдыхаю?
Как и 99% безыгорек тут.
Спасибо что разрешил, не буду.
>>1112886
Не люблю рогалики.
>>1112895
Был бы вайбкодей - уже давно играл бы в свой собственный нейрослоп. Алсо ты меня с кем-то путаешь.
Вахтер гд своими банами совсем отбил желание что либо делать. Хоть в холодильник лезть.
Все правильно. Я намедни поручил дипсику убрать артефакт -acne на персонаже. Он просто взял и убрал тень отбрасываемую персонажем на себя. Нет теней - нет багов.
>Алсо ты меня с кем-то путаешь.
Вы все на одно лицо. С чего вы вообще решили что будете играть в свою игру? Во первых разработка это не игра, а работа, во вторых даже если играть в одну и ту же сингл игру целый год - тебя воротить от неё будет.
Поэтому я все свои идеи запостил в ААААААА-тред, и сижу жду, когда украдут и заработают на них свой первый миллион.
(А я поиграю)
На практике еще оказывается что многие идеи говно. То есть, ты в моменты знаешь как улучшить геймплей той или иной игры. Как-будто что-то где-то реально понимаешь. Но начинаешься реализовывать свои идеи и они оказывается унылой какахой.
Конечно можно сделать игру на 2-10 часов.
Но я хочу реиграбельный шедевр. Иначе зачем еще один "попыт" делать.
Так что я даже ААААААААА-тред не листал толком, все какие /vg фантазии. Идея ничто - нескучный геймплей - все.
Желание сделать игру - это по сути неудовлетворённость от тех или иных чужих игр. Где тебе хотелось бы глубже или дольше или более интереснее.
Аноны которые шарят в движке, можно ли на нём сделать, оой бля как же это описать... В общем играли в This war of mine? вот задумка примерно такая, но вместо вида сбоку, будет вид сверху. Вместо стартового дома, я хотел бы сделать бомбоубежище, в которое на начало ядерной войны спускается рандомное количество человек (от 5 до 8), Персы имеют рандомизируемое СНГ-шное имя и фамилию, всё происходит во времена холодной войны (как мы уже поняли - жахнули). В чём вопрост, мне нужно хотя бы начать, сделать тестовую небольшую локацию и прописать всё от стартового меню игры до запуска обучающей миссии, которая к основному геймплею отношения иметь не будет а просто чтобы опробовать механики.
>Персы имеют рандомизируемое СНГ-шное имя.
Такое только анрил потянет.
Ты описал свою фантазию, а не техническую сложность. Но судя по примеру проблем вообще не будет.
>Аноны которые шарят в движке
Вообще не шарю. У меня айкью 32.
>В чём вопрост, мне нужно хотя бы начать, сделать тестовую небольшую локацию и прописать всё от стартового меню игры до запуска обучающей миссии, которая к основному геймплею отношения иметь не будет а просто чтобы опробовать механики.
Все что ты разрабатываешь, ты делишь на сцены. Мелкие сцены становятся дочерними сценами более крупных, те в свою очередь ещё более крупных. В любом случае будет сцена менеджер, которая будет тебе все это вместе из экземпляров собирать в геймплей. Прост в условном скрипте у тебя будет написаны условия сборки тестовых уровней с ограниченными механиками которые ты выведешь в инспектор. Очевидно что механики температуры или голода не должны ломать всю игру при выключении и должны быть изначально модульно спроектированы. Но вот это уже твои проблемы как реализовывать...
> чём вопрост, мне нужно хотя бы начать
Сделай главную ноду2(3)д, в неё всунь Контрол зеленая нода назови "меню", а так же ещё одну ноду2(3)д и назови "уровень", и так со всем что жизненно необходимо, а потом просто сиди и заполняй
Для выживастика скорее всего пользоваться не буду, тк читая терминал видел он там вообще все потрошит и щас страшно заглядывать в проект, но приятно что задумку все же смог добавить, тк сам бы не смог
А он подключен, все коммиты сделаны, можно будет откатиться, но в целом вроде оно не потребуется. Думаю займусь в ближайшее время парой карт, тк я их забросил по итогу из не имения смысла
>0,3%
Теперь уточки коровки на карте почти не жрут ресурс кадра.
Но теперь не очень хочется делать миникарту.
>В чем понт добавлять ноды прямо через код
Я вынужденно делаю так с некоторыми своими @tool-нодами, которые мне нужно вставлять в разные места в качестве чего-то вроде контейнера или утилитки. Если бы я использовал редактор, мне пришлось бы искать .tscn на диске, а если я добавляю все свои ноды из скрипта - я могу просто добавить ноду по её типу, так же просто, как и любую родную ноду Godot. При этом добавленные через код ноды не светятся в редакторе, если не добавить им owner, и не сохраняются на диск в tscn, поэтому не засоряют обзор "техническими" нодами, которых может быть довольно много.
>Чтобы работало на 0.000000005 наносек быстрее?
Нет, для ускорения обычно совсем отказываются от "нод", поскольку "ноды" - это обёртки над API "серверов" (servers), которые можно дёргать вручную, где и когда тебе захочется. По большому счёту, спавн нод из кода - совсем не рационален по производительности кода, но это намного удобнее для создания и поддержки кода программистом, чем обращения к низкоуровневым API серверов.
Отдельно отмечу, что спавнить Timer (ноду) нерационально, т.к. есть
>get_tree().create_timer(ms).timeout.connect(...)
Либо, для большего контроля, time += delta внутри _physics_process.
>Разница между колоссальная.
При чём тут разница, если вопрос был чётко поставлен о совсем другом: >>1112704
>почему [type casting] НАСТОЛЬКО анти-паттерн, что в 4.8 теперь [предупреждение]
>[тайп кастинг в] рантайме
Почему это считается антипаттерном?
>в геймдеве если попробую то я хотя бы буду в среде которая хоть немного мне нравится
В чём проблема попробовать прямо сейчас, не бросая основную работу, которая тебя кормит? Для следования туториалам для обучения всему необходимому достаточно 1-2 часа в день вечером. Если тебе это по кайфу, то забудешь о всех остальных развлечениях вроде кино, игр и прочего. Если тебе это будет в тягость, то с чего ты взял, что, бросив основную работу, тебе вдруг захочется заниматься геймдевом? На работе тебя начальник поди подгоняет и есть чёткие дедлайны, поэтому хочешь не хочешь, а делаешь. А соло инди геймдев - это борьба с самим собой, чтобы сесть за комп, открыть-таки редактор и поковыряться в файлах проекта... Без начальника, дедлайнов и ограничений многие люди не справляются, потому что слишком ленивы от природы. Успешными становятся только те, кто готов пахать через силу даже в отсутствии хозяина с кнутом, или те, кто настолько аутист, что монотонная и тяжёлая работа доставляет им удовольствие сама по себе.
Алсо, несмотря на
>Искусство никогда не умрет
Искусство редко приносит прибыль. Занимаются искусством, считай, сотни миллионов, а скольких из них ты знаешь по именам? Вот и считай, что те, кого ты знаешь по именам, успешно зарабатывают на жизнь, а все безымянные занимаются только ради удовольствия и чаще сливают в искусство все свои личные деньги.
>пять лет своего усиленного оубчения
Чтобы сделать свою первую простейшую игру, достаточно пары вечеров со старыми туториалами, даже без нейронок. Чтобы сделать игру уровня, допустим, Stardew Valley, нужно около пяти лет РАБОТЫ над игрой, а не обучения разработке игр; обучиться ты можешь по ходу работы. Но чтобы твоя игра уровня Stardew Valley смогла принести тебе хоть какие-то копейки, а тем более - окупить предыдущие пять лет и прокормить тебя хотя бы на год вперёд - нужны совсем другие усилия, не имеющие прямого отношения к разработке. Самый верный способ заработать как инди-геймдев - это собирать сообщество фанатов вокруг своей персоны или своей деятельности. Тебе нужны люди, которые пойдут за тобой и в огонь, и в воду, и будут набрасываться с когтями на всех твоих конкурентов. И ты должен собирать их в процессе делания игр, если их у тебя ещё нет. Поэтому разработка успешных инди-игр - это не про "усиленное обучение", а про создание медиа-персоны.
Если же ты хочешь работать на галере, то это совсем другая тема, не связанная с искусством, и пробиться на более-менее приятное место намного сложнее из-за огромного количества желающих и малого количества нормальных вакансий. Сейчас ты конкурируешь с 500+ сотрудниками, через лет 5 будет больше 1000 на место. И работа будет такой же неблагодарной, как и в любой другой отрасли, если ты не глава студии, лол.
>>1112785
>"игр" скоро станет больше чем игроков
Ты упускаешь то, что это не игры, а буквально цифровой шум, среди которого приходится искать реальные продукты, достойные твоего внимания. И именно поэтому у тебя должно быть сообщество фанатов ДО того, как ты начнёшь делать игру для них. А те, кто просто так заливает в стим какую-то поделку, абсолютно ничем не отличаются от тех, кто делает никому ненужную поделку и пытается продать её в переходе метро...
>>1112871
>>Алын
>Каво?!
Это термин из покера, "all in": когда ты ставишь все свои фишки. Если ты выиграешь, то получишь все фишки обратно и ещё чужие. Если проиграешь, то потеряешь все свои фишки и не сможешь больше продолжать игру. В переносном смысле означает, что человек вкладывает 100% своих ресурсов в какую-то рискованную деятельность, так, что в случае провала он потеряет слишком многое. Типа брать кредит под бешеный процент для открытия бизнеса, рискуя лишиться всего имущества в случае провала.
>>1112801
>Единственное что нейронки не сделают - это не скажут тебе, что нужно делать.
Вот очень жаль, что они этого не делают. На вопрос "зачем жить" постоянно какая-то унылая копипаста... Не всё ли равно, что там нейронки умеют и могут сделать, если они не дают смысла для жизни? Какая разница, умрёшь ты богатым и несчастным или бедным и несчастным? Без смысла жизни всё остальное бессмысленно.
>Там весь текст нарисовали в виде левелов. А это еще труднее.
Просто делаешь побольше двусмысленностей и пусть игрок сам ломает голову над тем, что тут произошло. Если ты пишешь текстом "Фалько: Маша, дарю тебе квартиру!", то это банально и уныло, в этом нет ничего интересного. А если ты создаёшь квартиру, в которой полный бардак, недоеденная еда в тарелках, повсюду бельё разбросанное, а где-то на столе окровавленный чек на десять миллионов рублей - это уже интересно, заставляет игрока поломать голову над тем, что тут произошло и почему. Даже если у игры не будет развязки, она может создать разные теории фанатов, движуху вокруг себя - это главное. При этом для такой сценки не надо много ума, ты просто не расставляешь ассеты строго по сетке и получается что-то такое, разве нет?..
>Два рана с одними и теми же шмотками = смерть рогалика
По-моему, ты в какие-то неправильные "рогалики" играешь, если для тебя в рогалике "шмотки" важнее данжей. Рогалик - это dungeon crawler с процедурной генерацией этих самых dungeon. Даже если у тебя всё время одни и те же Iron Sword, Round Shield и Leather Armor, прохождение процедурного данжа будет, в идеале, каждый раз разным - потому что ты не знаешь, за какой дверью спрятался монстр, по какому коридору тебе нужно идти, где находится ловушка и т.д. Процедурность создаёт непредсказуемость локации, а локация - это движение, поэтому ты не можешь "одинаково" пройти процедурную локацию. Тут, конечно, нужно понимать, что если процедурный генератор имеет мало шаблонов/этапов работы, то данжи будут похожи друг на друга - но это совсем не "шмотки", и даже не "противники", а совсем другая концепция. Какое-то разнообразие шмоток - бонус, но без процедурной генерации данжей этот бонус бесполезен.
>спустя пару месяцев игры приедается
Полторы тысячи часов - это провал?.. Ладно, сто двадцать часов, если играть по 2 часа в день. Мне кажется, ты ожидаешь слишком большой реиграбельности от типичной инди-игры. То, что твой игрок возвращается на протяжении ДВУХ МЕСЯЦЕВ - это уже огромное достижение, нет?
>не про шутер. Залипательность это больше про визуал, подачу, эффекты, звуки, азарт.
То есть, по-твоему, можно создать "шутер" без визуала, эффектов, звуков и азарта? Как?
>а брожение по пустошам нет
В каком месте "брожение" является "шутером"? Ты путаешь с "симуляторами ходьбы"...
Повторюсь, ты в какие-то неправильные игры играл, если у тебя такое понимание жанров... А, впрочем, виноват не ты, а ширнармасса игроков, которые ставят неправильные теги в стиме, обзывая "рогаликом" или "шутером", всё, что лишь отдалённо может напоминать какие-то предыдущие игры в этих жанрах.
>сам бы не смог
У тебя же банальный тест 1 на 1, поди ещё и по локалке, а не через половину планеты. Слепить такое на коленке по туториалам проще некуда, тем более что в Godot уже есть всё необходимое API - и низкоуровневое, и высокоуровневое - изобретать велосипед не надо, но и не сложно.
>щас страшно заглядывать в проект
А придётся, потому что накидать примитивный мультиплеер =/= поддерживать мультиплеерную игру. Если твоя игра взлетит хоть немножечко, посыпется куча проблем, и не факт, что клод сможет все их адекватно исправить без "переписывания всего с нуля" и подмоченной репутации...
Короче, поменьше доверяй и побольше проверяй. Как минимум нужен тест с 200+ мс пингом и 10-15 игроков на одной карте, физически находящиеся на разных континентах, подключённые через VPN и соревнующиеся в матче, а не просто так бегающие без какой-либо игровой цели.
А потом тебя ждёт борьба с читерами VS нечаянные баны честных игроков, честный матчмейкинг, поддержка серверов на каком-то более-менее живом и не очень дорогом железе, вечно скулящие на форумах игроки и проведение ивентов ради них, и т.п. Геймдев уровня "хардкор".
>если твоя игра взлетит хоть немножечко
Лол. Сейчас стим завален вот такими играми, сделанными с помощью одного промпта, и этот нейрослоп никто не покупает из принципа, буквально «zero review game» из палаты мер и весов. К сожалению (или к счастью) пролетариат сливается, когда начинается технодрочерство с багфиксами и намеками на то, что разработчику СЛЕДОВАЛО БЫ знать из чего состоит его игра под капотом. Естественный отбор работает и это прекрасно.
Ты тупой, я тебе ответил. Первый рантайм, второй комптайм (должен, но гдскрипт удивляет).
Нет, ты не ответил ни на что.
>Первый рантайм, второй комптайм
Я это и без тебя знаю - я спрашиваю, почему "null" называют "unexpected" и по умолчанию (начиная с версии 4.8.beta1) отмечают это поведение как "warning"? Что плохого в том, что у меня кастинг типа в рантайме выдаёт null и крашит весь проект при обращении на null? В чём проблема? Почему Godot требует от меня исправить это? С какой целью? Мне нужны конкретное объяснения, а не вялое "ну тут рантайм, а тут нет" - это НИЧЕГО не объясняет, потому что вопрос вообще не в том, что там рантайм, а что нет. Ты не понимаешь?
Ладно, можешь не напрягаться - Gemma пояснила, что всё ОК, могу продолжать как раньше.
>мне неинтересно играть в игру, в которой я заранее знаю каждый пиксель
Ты слишком переоцениваешь возможности человеческой памяти, либо ты относишься к тому 0.00000000% людей с эйдетической памятью, которые могут запомнить всё словно фотоаппарат и вспомнить всё до пикселя спустя несколько лет разработки игры. Я даже мелкие прототипы забываю так, что потом открываю словно совершенно чужую игру.
>В играх из-под нейронки хоть какой-то элемент неожиданности есть
Судя по тому, что я видел у LLM в целом, "неожиданность" там только первые несколько раз, а потом ты начинаешь видеть паттерны конкретной LLM настолько, что тебе уже не нужно ничего ей промптить, чтобы узнать её ответ - просто представь промпт и сразу в голове у тебя будет на 99.999999% правильный ответ от конкретной модели, мгновенно.
>чистая процедурка подходит больше для технодемок чем для поиграть с удовольствием
Что ты имеешь в виду? Вот мир Minecraft почти на 100% "чистая процедурка" из обычного шума Перлина или чего-то вроде него. Там есть дизайнерские постройки, типа домиков жителей и кусочков подземных данжей, но они не так важны, как мир в целом. И многие инди-игры сегодня используют в целом похожие техники, потому что это развлекает.
>>1113016
>Не люблю рогалики.
Это потому что у тебя нормального рогалика не было...
>>1113022
>С чего вы вообще решили что будете играть в свою игру?
А зачем вообще делать игру, в которую не будешь играть?..
>если играть в одну и ту же сингл игру целый год - тебя воротить от неё будет
А кто будет выполнять ежедневные задания и гриндить на скинчики, если не ты?
>>1113027
>начинаешь реализовывать идеи и оказывается уныло
>Но я хочу реиграбельный шедевр. Иначе зачем
>Идея ничто - нескучный геймплей - все.
Твоя проблема в том, что ты ищешь некую "правильную идею", которая тебе прям сразу все вопросы закроет и сделает "нескучный геймплей" в пустой папке проекта. На деле так не бывает, и никакая "идея" сама по себе не бывает "правильной", не создаёт "нескучный геймплей" на ровном месте. Даже знаменитый Minecraft это не просто "идея кубиков".
В реальности ты должен работать итеративно. Вот ты набросал свою идею "как RimWorld, только с более продуманными рейдами" (это ведь твоя идея была?), но что-то не то - неинтересно играется. Анализируешь свои ощущения, задавая себе наводящие вопросы, и пробуешь поменять значения формул, управляющих геймплеем... и снова тестируешь.
Шаг за шагом вносишь правки - тут дамаг побольше, там защита послабее, вот тут нужно упростить спавн юнитов, а здесь врагов выстроить по-другому... И ты входишь во вкус, погружаешься в мир своей игры как его творец, получаешь удовольствие от того, что проект принимает более интересную, более развлекательную форму. В этом фан.
Потом, конечно, нужны внешние плейтестеры, потому что "глаз замылился" и ты уже не замечаешь некоторых вещей, потому что привык к ним. Без оценки другими людьми ты рискуешь сделать что-то, что понятно и интересно только тебе. Но главное - независимо от того, кто высказывает свои мысли, изменения геймплея должны быть маленькими.
...нет. Главное: Godot - это игра. И все мы играем в него, пока делаем свои игры.
Чтобы быть успешным, нужно полюбить процесс геймдева, а не результат.
Потому что первый вариант говнопрактика приводящие к подводным в рантайме. Тебе говорят - больше не делай так, это плохо. Делай теперь хорошо.
Что тебе еще нужно услышать?
>Что плохого в том, что у меня кастинг типа в рантайме выдаёт null и крашит весь проект при обращении на null?
>что плохого в том что проект рухнул
Ну я даже хз, да ничо плохого наверное...
>У тебя же банальный тест 1 на 1, поди ещё и по локалке
Всмысле по локалке, с одного компа/по проводу? Нет, сервер создается в стиме и чекает его сервера во внутреигровом браузере. А так, тестили втроем
>Слепить такое на коленке по туториалам проще некуда
Нууууу хуй знает честно говоря, это же комплексная задача, недостаточно просто синхронизировать позицию и повороты, я поэтому по итогу забросил его, ещё больше работы которая не факт что будет иметь смысл
>Как минимум нужен тест с 200+ мс пингом и 10-15 игроков на одной карте
Это да, согласен, думал поискать в тг каналах, но скорее всего не смогу такую пачку собрать. Да и руководить не хочу
>Если твоя игра взлетит хоть немножечко
Вот взлетит, тогда и посмотрим. Что щас то бухтеть...
https://dtf.ru/indie/5372062-sozdanie-indi-igry-unmotivated-heroes-na-godot-s-pomoschyu-ii
>В итоге вдвоем за 2 месяца собрали демо для фестиваля «Играм быть», суммарно чуть меньше чем за полгода довели проект до Раннего доступа в Steam,
>смесь симулятора уборки и ремонта с элементами лайфсима от первого лица.
>В течение первого месяца разошлось порядка 50–60 копий.
Это не игра, а буквально использование базовых узлов в качестве основных механик. Любая серия видосов для полных новичков по годоту выдает более интересный результат чем это. Перенос вещей с примитивной физикой и хождение это просто начало начал, базовые основы как работают узлы. Это то что может написать ребенок сам имея доступ к интернету, но тут какие-то люди в команде используя нейронку... Я просто в ахуе. Даже с нейронкой которая буквально говорит какие узлы куда кидать и скрипты крепть, они смогли сделать лишь это. Охуеть.
Кто говорил, местный додик-луддит, который до нормальных нейронок так и не добрался? Годот уникально подходит к нейронкам за счет своей открытости сорцов и текстовости буквально всего, материалов, сцен, шейдеров. Пока всякие хуйрины костыляют себе MCP/скиллы/плагины, любая нейронка просто берет годот и делает на нем что угодно нативно. Больше чем годот подходит только какой-нибудь threejs.
>Godot MCP-сервер. Инструмент, позволивший подключить ИИ напрямую к запущенному движку, чтобы модель могла видеть структуру сцен и нод, а не гадать вслепую.
Оно и так видит епта блять, все текстовое. Даже туповатый гемини с этим справляется. Клод же хуячит полный проект на раз-два.
>Клод же хуячит полный проект на раз-два.
Если это так, то почему ты такой безыгорный?
Ах, точно. Игры Клода не делают тебя игорным...
>>1113168
Вот я не понимаю, чего добиваются эти люди. Они в буквальном смысле убили 2 месяца на разработку бесполезного мусора, который, с их же слов, почти неинтересен игрокам. Они реально мечтали именно о разработке симулятора уборки? 9001-го по счёту? Из совершенно унылых ассетов, которые, хотя и были сгенерированы, но выглядят так, будто я их лет пятнадцать назад видел в нескольких играх?
Представьте себе: у вас в руках волшебная палочка, способная создать абсолютно что угодно, совсем без ограничений, почти бесплатно и почти мгновенно... И достаточно лишь пожелать. И что же вы желаете? Вы желаете "симулятор уборки №9001"? Зачем? Это всё настолько абсурдно, что просто не верится. Эти люди реально чему-то обучены, способны говорить и даже записывать свои мысли текстом, но их желания - это "симулятор уборки"? Будто их самих сгенерировали, использовав самые распространённые шаблоны.
Тем временем:
>BioWare объявила о закрытии — спустя 31 год работы.
>Производство следующей части Mass Effect прекращено.
>BioWare была основана в 1995 году. За время работы студия успела выпустить оригинальные Baldur's Gate, Neverwinter Nights, Star Wars: Knights of the Old Republic, несколько игр серий Dragon Age и Mass Effect, а также Anthem.
Почему ИИ не помог им делать все эти игры? Что им помешало перейти на Godot с GenAI, чтобы быстрее разработать продолжения всех этих игр и не стать банкротами? Они что, тупые? У них в руках реальная волшебная палочка - а они пожелали закрываться?..
>Всмысле по локалке
У Steam есть какие-то свои сервера в нескольких крупнейших городах России. А интернет в пределах большого города - это всё равно что локалка - пинг максимум 30 мс, считай что нет его. Т.е. пока всё расположено в одном городе (Steam, игроки), пинг минимальный и никто не страдает. Если в твою игру залетает кто-то из другой страны, у него пинг 150+ и начинается рассинхрон, когда кто-то вынужден бить на упреждение и при этом сам отлетает от чего-то, что неспособен даже заметить, пока не умрёт.
Так что сделать нормальный экшен мультиплеер чрезвычайно трудно, особенно из-за сложности с тестированием (можно симулятор лагов и потери отдельных пакетов создать, но кто-то же должен реалистично управлять персонажами в игре).
Смотрите, как это делается:
1. Создаёте сцену с заглушками.
2. Добавляете эту сцену в другие сцены.
3. Пытаетесь запустить игру => Godot не даёт.
4. Добавляете $Node as Node => запуск успешен.
5. Когда начинаете расширять, пишите if node...
6. Итого:
- проект легко запускается;
- нет беспричинных крашей по null;
- подсветка и автодополнение работают;
- ошибок в консоль не выводится => багов нет.
Вы так никогда не делали?
>что плохого в том что проект рухнул
А что хорошего в том, что Godot тупо игнорирует все "непонятные" скрипты GDScript, когда встречает в них минимальный баг? Представь себе, у тебя есть меню, которое имеет строчку наподобие такой:
>@onready var bar: HBoxContainer = $Bar
Ты изменил тип ноды Bar в сцене с HBoxContainer на произвольную другую ноду Control, и это вызывает у GDScript истерический припадок, из-за которого ВЕСЬ скрипт меню, а следовательно, и всё это меню, тупо отваливается и не работает, хотя игра не крашится.
Значительно лучше сделать так:
>@onready var bar := $Bar as Control
1. Нас не парит, если Bar - любой из потомков Control.
2. Нам нужен краш, если Bar в принципе отсутствует.
3. Когда нам не нужен краш, мы просто делаем:
>if bar: bar...
И таким образом убиваем трёх зайцев разом.
Так почему это теперь считается некорректным?..
> Годот уникально подходит к нейронкам за счет своей открытости сорцов и текстовости буквально всего, материалов, сцен, шейдеров. Пока всякие хуйрины костыляют себе MCP/скиллы/плагины, любая нейронка просто берет годот и делает на нем что угодно нативно.
В хуйрине есть наниты и люмены. Где аналоги люменов и нанитов для годота? Как же так, почему ИИ-шка не высрала их ещё? У неё же все исходники есть.
Всё остальное работает абсолютно одинаково. Вот и получается, что исходники нужны только для продвинутого графона. Но продвинутого графона на годоте нет и пока не видно на горизонте.
Ах да, напоминаю, что у хуйрина исходники тоже есть. Отдельный вопрос, почему нейрододи нишмагли до сих пор запилить полнофункциональную поддержку вебгпу в хуйрине.
На самом деле ответ на вопрос простой.
Потому что нейронки говно.
Любые.
Даже топовые аргон и астра.
И вы говноеды, если платите корпам за юзание этого кала.
>Представьте себе: у вас в руках волшебная палочка, способная создать абсолютно что угодно, совсем без ограничений, почти бесплатно и почти мгновенно... И достаточно лишь пожелать. И что же вы желаете? Вы желаете "симулятор уборки №9001"? Зачем? Это всё настолько абсурдно, что просто не верится. Эти люди реально чему-то обучены, способны говорить и даже записывать свои мысли текстом, но их желания - это "симулятор уборки"? Будто их самих сгенерировали, использовав самые распространённые шаблоны.
Ни убавить ни прибавить. Паджитизм он такой, не лечится и нейронками не купируется. Но есть паджиты-энжоеры, а есть мастеры йода, которые за те же 2 месяца могут собрать иишкой из готовых ассетов очень крупный, уникальный проект, и разумеется - нигде не скажут что это был ии, потому что это будет вредить продажам. От них исходит основная опасность, от людей, которые знают как склонировать твою франшизу в 1 промпт, перемешать ее с другой, подобрать ассеты по стилистике и догенеровать и выложить рабочий продукт, и всё это за месяцы. Люди, с квалификацией в геймдеве и огромным опытом разработки, те самые убийцы джунов.
>Почему ИИ не помог им делать все эти игры?
Потому что студия мертва. 10 лет провалов, все кто хоть немного имел мозги - оттуда ушел 5-6 лет назад, после их последнего провала с игрой про меха. Мне кажется что студия была мертва давно, и единственные кто там работали был инклюзивный квир-сторож и инклюзивная небинарная уборщица, а сейчас ea просто решила что пришло время огласить как есть.
>В хуйрине есть наниты и люмены. Где аналоги люменов и нанитов для годота? Как же так, почему ИИ-шка не высрала их ещё? У неё же все исходники есть.
Квалификация нужна. Ну и большинство не претендует на люмены или наниты, потому что у годота достаточно проблем и без люменов с нанитами.
>Всё остальное работает абсолютно одинаково. Вот и получается, что исходники нужны только для продвинутого графона. Но продвинутого графона на годоте нет и пока не видно на горизонте.
Ну я вот написал иишкой пару патчеров шаблонов экспорта (кода движка по факту) для моей игры, чтобы убрать кое-какие лишние годотовские костыли. Уже неплохо. Ковырять движок тоже можно, как минимум для понимания что где может тормозить, но лезть в код неохота никому, мы игры делаем, а не доделываем за хуаном его проебы.
>Ах да, напоминаю, что у хуйрина исходники тоже есть. Отдельный вопрос, почему нейрододи нишмагли до сих пор запилить полнофункциональную поддержку вебгпу в хуйрине.
У них в лицензии буквально написано что запрещено использовать для нейрообучения. Да и вебгпу ему не помогут, один только движок это 100мб всякого разного говнеца которое придется качать в вебе каждый раз при открытии игры, без учета самой игры.
>склонировать твою франшизу в 1 промпт
Значение знаешь? Что будешь делать, если, скажем, заполучишь исходные коды и 3D модели Overwatch? Понимаю, не самая популярная игра, но всё же у них мерчендайз есть и всё такое. Что даст 1-в-1 клон с нейронками? Кто в это будет играть бесплатно?
>вредить продажам
Тот, кто думает о продажах, изначально проиграл. Я, например, после введения санкций играю только в пиратские и f2p игры без рекламы и без донатов. Не понимаю, зачем люди делают игры ради денег - что, недостаточно рабочих мест в вашем ИРЛ городе?
>>1113181
>наниты и люмены
Нам не нужно этих костылей в Godot.
>Потому что нейронки говно. Любые.
Полегче с высказываниями, ты пугаешься чисто на корпоративные облачные "Generative AI", а не на "все нейронки". Для справки, нейросеть создать может абсолютно любой, даже новичок в кодинге, ибо для нейросетей не нужно ничего, кроме условного:
>for w in weights.size(): sum += input[w] × weights[w]
>return sum > 0
Всё, примитивная нейронка создана, можно дальше расширять и дополнять разными приколами и т.п. Ознакомься со статьями в Википедии и уже сможешь создавать интересные нейронки даже на GDScript, без необходимости в каких-то библиотеках и т.п.
>Значение знаешь? Что будешь делать, если, скажем, заполучишь исходные коды и 3D модели Overwatch? Понимаю, не самая популярная игра, но всё же у них мерчендайз есть и всё такое. Что даст 1-в-1 клон с нейронками? Кто в это будет играть бесплатно?
Я не знаю ни одной успешной игры-сервиса от инди-разраба. Клоны овервотча делали и до ии, вон относительно недавний обсер сони на 400млрд, делался до иишной эпохи. Сделать успешную игру-сервис - все равно что выиграть в казино. Речь про клонирование другого рода. Клонирование механик, удачных игровых решений, каких-то новых идей с того же стимфеста. Ведь ии - это не только про код, а и про очень сильно бустанувшийся рисерч информации. Вместо того чтобы вручную искать гемы - можно натравить бота искать их за тебя, отмечать необычные игровые решения, не входящие в тирлист, искать готовые реализации нужных механик, распаковывать игры как консервные банки с целью извлечения ассета или кода реализации, затем компоновка, теми же агентами, согласно утвержденному человеком плану. Больше половины моих потраченных токенов - это токены поиска информации и составления и редактирования планов.
>Тот, кто думает о продажах, изначально проиграл. Я, например, после введения санкций играю только в пиратские и f2p игры без рекламы и без донатов.
Так не бывает. Пиратам тоже надо даже не просто есть, а хотябы платить за сервер, ты может и не донатишь, но другие - донатят, иначе такой сервер быстро закрывается или переносится на самый захудалый хост который еле дышит и часто падает, если пират этим занят из любви к искусству
> Не понимаю, зачем люди делают игры ради денег - что, недостаточно рабочих мест в вашем ИРЛ городе
Круто когда за хобби платят. Идти в геймдев чисто за бабками бессмысленно, потому что за то же потраченное время кабанчик тебе заплатит куда больше, чем ты скорее всего заработаешь. Геймдев, даже идущий за деньгами - или дурачок или всё выкупающий меценат, которому нравится делать игры и он готов вьебывать свое время дешевле чем оно стоит на рынке.
>Речь про клонирование другого рода. Клонирование механик, удачных игровых решений, каких-то новых идей с того же стимфеста.
Ты говорил про франшизу. Значение знаешь?
https://ru.wiktionary.org/wiki/франшиза
>Пиратам тоже надо даже не просто есть, а хотябы платить за сервер
Не знаю, о чём ты, но миллионы людей совершенно бесплатно сидят на раздачах торрентов, при том это возможно делать даже с мобильных телефонов...
>Круто когда за хобби платят
В чём твоё хобби? Писать Клоду промпт:
>Найди самые крутые инди-игры в Стиме и сделай клон, который принесёт мне миллиарды прибыли.
Это не хобби, а золотая лихорадка. Ты не получаешь удовольствие, но тратишь время и деньги на лопаты и попытку добыть золото. А выигрывает в итоге кто? Продавец лопат, и единицы тех, кому тупо повезло.
Если честно, вообще не понимаю, зачем игры делать. Например, я скачал за последние годы сотни разных бесплатных игр с itch.io - сколько из них хотя бы раз запускал? 1% в лучшем случае, остальные лежат в специальной папочке "нужно поиграть", но я уже не поиграю... Так в чём смысл? Ради чего эти люди так старались, если я даже не запущу их игру бесплатно? Десятки, сотни тысяч игр даже не скачаны мной - не интересны, не заслуживают внимания, или просто не наткнулся/не смог найти в игропомойке, в которую превратился интернет. И даже с блокировками эти бесконечные потоки игрошлака не прекращаются, поскольку тот же Яндекс, ВК и прочие не банят...
Может, мы свернули куда-то не туда? Может, правы были те, кто говорил "потрогать траву", "оторваться от экрана", "выйти на улицу" и прочее подобное... Да не, не может такого быть. Так в чём же проблема?..
Чёт уже не хочется ничего делать...
>Может, мы свернули куда-то не туда? Может, правы были те, кто говорил "потрогать траву", "оторваться от экрана", "выйти на улицу" и прочее подобное
Кста блен, были в последнее время такие же мысли, и в ходе измышлений все же согласиля с ними, нужно по чаще выходить на улицу и к играм относится проще
>Ты говорил про франшизу. Значение знаешь?
Овердроч на франшизу не сильно тянет, ее вторая версия сдохла. Если ты вдруг не знал - у успешных инди есть свои мини-франшизы(по меркам условного ассасина)
>Не знаю, о чём ты, но миллионы людей совершенно бесплатно сидят на раздачах торрентов, при том это возможно делать даже с мобильных телефонов...
Меня смутило
>>1113189
>фритуплей
Так обычно называют онлайн игры а не синглы. Пиратские синглы обычно просто именуются пиратками бпз всяких фритуплей. Полностью поддерживаю, кстати, в жизни ни одной игры не купил
>В чём твоё хобби? Писать Клоду промпт:
Так пишет профессиональный вор который твою игру спиздит быстрее чем ты релизнешься, pvkk спиздеть не даст. Я обычно прошу "найди реализации механики", "найди игры с механикой", "вот тебе декомпиляция - извлеки механики и встрой их в мою архитектуру" и все в таком духе. Вот недавно искал, ка народ делает баланс и экономику в играх, собрал себе набор эксель табличек с экономикой такой как я хочу но описанной нормально математически.
>Это не хобби, а золотая лихорадка. Ты не получаешь удовольствие, но тратишь время и деньги на лопаты и попытку добыть золото
Я лично - получаю удовольствие. Играть в игру которую ты делаешь по саоему вайбу это круто, иногда просто сижу залипаю в то что получается.
>Если честно, вообще не понимаю, зачем игры делать. Например, я скачал за последние годы сотни разных бесплатных игр с itch.io - сколько из них хотя бы раз запускал? 1% в лучшем случае, остальные лежат в специальной папочке "нужно поиграть", но я уже не поиграю... Так в чём смысл? Ради чего эти люди так старались, если я даже не запущу их игру бесплатно? Десятки, сотни тысяч игр даже не скачаны мной - не интересны, не заслуживают внимания, или просто не наткнулся/не смог найти в игропомойке, в которую превратился интернет. И даже с блокировками эти бесконечные потоки игрошлака не прекращаются, поскольку тот же Яндекс, ВК и прочие не банят...
Так зачем ты берешь игры на помойке? Может ты себе уже этим импотенцию игровую заработал
Что значит сцену с заглушками? Сцена это модуль.
Родитель должен инициализировать сцену (модуль) раз он себе её подключает.
Модуль как бы говорит - я ничего не знаю о твоем мире - но мне нужен - игрок, тайловая карта и спавнер - дай мне их и я буду работать в любом проекте.
То есть, модулю нужны только dependency и в идеальном мире это должны быть интерфейсы.
Как это работает - через год ты открываешь модуль пули и ты просто смотришь на "контракт" (dependency) и понимаешь для этой пули даже не нужен модуль оружия, он только зависит от position и модуля звука.
То есть, ты уже не теребишь кишки сцены - а сидишь думаешь на уровень выше - модулями.
>Я не знаю ни одной успешной игры-сервиса от инди-разраба.
Палворлд?
>Почему ИИ не помог им делать все эти игры? Что им помешало перейти на Godot с GenAI, чтобы быстрее разработать продолжения всех этих игр и не стать банкротами? Они что, тупые? У них в руках реальная волшебная палочка - а они пожелали закрываться?..
Справедливости ради, они просто сидят и ждут. Права на франшизу это актив. И им нельзя разбрасываться просто так. Нужно удобное время. Тот же реймейк облы сделали в относительно подходящее время с относительно удобными и простыми средствами - успех. Реймейки гта вс и са делали чуть более халтурно и прогадали. А эти хотят дождаться момента, когда можно будет реально масс эффект 4 сделать одним промптом. Сейчас пока нейронки не тянут. Потом потянут. И только владелец франшизы сможет такое продать. По сути монетизировать ностальгию игроков.
>ну эти самые инди разработчики с бюджетом смуты в кармане
>Овердроч на франшизу не сильно тянет
У них там и мультики, и комиксы, и порнуха (ладно, порнография не официальная, формально "фан-арт"). Медиафраншиза как она есть. Ты же не думаешь, что "франшиза" - это только когда больше 1 игры с одним названием? У франшизы может быть и всего 1 игра.
>>фритуплей
>Так обычно называют онлайн игры
Не... "Free to play" - это игра, в которую ты можешь совершенно бесплатно играть, но в ней есть какая-то монетизация вроде "скинов", "ускорялок" или просто рекламных баннеров. Например, на Яндекс.Играх все бесплатные игры - это "free to play". Мультиплеер тут является только дополнительным стимулом - люди значительно чаще покупают скины для того, чтобы похвастаться, а не просто дрочить в одиночестве.
>в жизни ни одной игры не купил
Я раньше покупал часто для "поддержки разраба", но, на сегодняшний день, видя количество нейрослопа и ассетфлипов, желания поддерживать это уже нет.
>Так пишет профессиональный вор...
>Я обычно прошу "найди реализации механики", "найди игры с механикой", "вот тебе декомпиляция - извлеки механики и встрой их в мою архитектуру" и все в таком духе.
Т.е. пишешь как вор-любитель? Лол... Эх, я бы тебе в подробностях объяснил, в чём ты не прав и как тебе следовало бы работать (с нейронкой), но зачем...
>Играть в игру которую ты делаешь по саоему вайбу это круто, иногда просто сижу залипаю в то что получается.
Тут не поспоришь, но смысл копировать чужие игры, если ты можешь просто в них играть? У меня вот даже купленных игр сотни, и я большинство даже не скачал ни разу, а те, что скачал - не запускал. Как бы, если бы я хотел поиграть в чужую механику - я бы просто поиграл, не напрягая никакие нейронки...
>Так зачем ты берешь игры на помойке?
А где их брать?
Гугл плей - помойка.
Стим - уже помойка.
Эгс - супер-помойка.
Итч.ио - инди-помойка.
Мелкосайты - все до единого - помойки.
Нинтендо, сони, и т.п. - огороженные помойки.
Игр много, и все они кучкуются на этих помойках...
>>1113210
>реально масс эффект 4 сделать одним промптом
>только владелец франшизы сможет такое продать
Если не наступит третьей мировой и если не будет тотального уничтожения мировой компьютерной инфраструктуры, и если ИИ позволят развиваться свободнее, то: а) любой игрок сможет получить игру бесплатно по тому же самому промпту; б) даже если ограничить доступ к промптилке, у игроков не будет денежных средств для покупки, потому что работу выполняют роботы, а мясные мешки не нужны; в) в нереальном случае, когда у игроков есть деньги, эти средства больше не нужны владельцу компании, т.к. достаточно попросить ИИ и он что угодно сделает совершенно бесплатно - хочешь, яхту из золота, или огромную толпу клонированных шлюх, или отправит исследовать космос и брать инопланетянок в гарем.
>Что значит сцену с заглушками?
То и значит. Ты же в прошлых тредах тут хвастался, насколько круто делать "сверху вниз", когда у тебя существует внешняя оболочка, а кишки болтаются в бесформенных пустотах. Заглушки - это как раз эти внутренности, отсутствующие по причине того, что не созданы, не до них сейчас. Что-то типа простой Node, исполняющей роль TODO в дереве сцены, которая в будущем сменит свой класс на конкретный. И ты её подключаешь в код, пишешь для неё функционал, но блокируешь его выполнение, т.к. ноды ещё нет (null). Заглушка. И тебе нужно, чтобы проект стартовал без необходимости превращать все эти заглушки в более конкретные реализации, т.к. тогда тебе нужно будет реализовать всю твою GTA 7 за один присест...
Даже если разрабатывать снизу вверх, всё равно в некоторых случаях нужны заглушки, поскольку ряд соседствующих систем может быть созависимым и неизвестно наверняка, какая нода потребуется до плейтестирования всего проекта в текущем виде.
>Родитель должен инициализировать сцену
Ты описал всего один способ из множества.
>Если
Ну, да, "если". Игра в долгую. С шансом сорвать куш или проебать.
Че ты за них так переживаешь?
>любой игрок сможет получить игру бесплатно по тому же самому промпту;
Про бесплатно не было речи, такого пока нет на горизонте. Корпы будут ждать момента, когда ИИ сможет сделать такое, но не за 100-1000 долларов, как делают нативные порты клодом сейчас, а за 100К-1КК в пересчете на токены и с минимальной доработкой руками. Для среднего васяна это будет дорого, а для корпов ультрадешево. При этом публичные реализации от энтузиастов раньше их собственной они будут банить по DMCA.
Просто используй типизацию у тебя будет заглушка, не надо null к объекту кастить.
>"сверху вниз"
Это относиться к поведению, а не состояниям.
То есть, ты думаешь создам я радио - у него будет методы:
-задать частоту
-искать станцию
-увеличить громкость
-уменьшить громкость
итд
Ты вообще не думаешь (пока) что там и как будет внутри (какие состояния) - это и есть сверху вниз, ты думаешь интерфейсами (поведением).
>можно симулятор лагов и потери отдельных пакетов создать
Спасибо за идею для моей первой игры. Никак не мог придумать.
> от чего-то, что неспособен даже заметить,
Когда играли в раст у челеков с европы пинг 15-30, у тебя 90. Ты стреляешь в него, потом в логи смотришь, а ты стрелял в стену (или вообще не определено). Мало того что одни читаки и киберкотлеты, так ты еще воюешь в другом времени.
Но я думаю виной говнокод самого раста, как можно фиксировать стрельбу, но неопределить куда попадание.
>Играть в игру которую ты делаешь по саоему вайбу это круто
>по вайбу
В переносном смысле надеюсь?
>ты думаешь создам я радио - у него будет
Интерфейс: кнопки, индикаторы, надписи и т.д. Но конкретный дизайн может поменяться. А в Godot множество дизайнерских фич == классы нод.
Допустим, планируешь popup интерфейс для радио, появляющееся и исчезающее при смене канала или аудиотрека на канале. У него будет базовая нода, и, соответственно, тебе нужна ссылка на неё, чтобы, ну, например, сделать плавное modulate через Tween. Технически ты можешь сделать это и по-быстрому протестировать даже с простым ColorRect, но тебе в будущем потребуется изменить тип на что-то иное.
Т.е. у тебя такая штука:
>@onready var popup: ColorRect = $Popup
И код типа такого:
>if popup: ... tween_property(... "modulate" ...)
И всё бы ничего, но твой проект не будет нормально запускаться и работать, если $Popup окажется не наследником ColorRect, а каким-то другим Control или вообще будет отсутствовать. Поэтому ты делаешь:
>@onready var popup := $Popup as Control
И всё просто работает, без проблем.
Да, это можно по-другому решить, но вот так тоже возможно, движок это позволял делать много лет, я буквально привык к этому, так ПОЧЕМУ ВНЕЗАПНО ВЫВОДИТСЯ ПРЕДУПРЕЖДЕНИЕ О НЕОЖИДАННОМ (unexpected) NULL, ЕСЛИ Я ЕГО ТУТ О Ж И Д А Ю ???
Я хз к чему ты там привык - делай инжекты. Целый класс проблем решиться.
child_scene.popup = current_popup
child_scene.other_dependency = current_other_dependency
>движок это позволял делать много лет, я буквально привык к этому,
Я когда увидел каст в определение - меня наоборот передернуло. Благо они развиваются - развивайся и ты.
>если $Popup окажется не наследником ColorRect, а каким-то другим
Я вообще это безумие не понял. То есть, кто-то не отнаследован но каким-то боком кастуется?? Не пытайся придумать свое программирование. Перечитай еще раз про полиморфизм.
Вроде тебя понял немного. Смотри.
Если что приведение типов (каст) и полиморфизм (присваивание к предко) это два разных направления.
То есть, ты передал в функцию Животное. А потом каким-то хером ты знаешь что Животное это Собака и в функции кастуешь из животного в Собаку.
Это выглядит плохо, но ты можешь проверить через instanceof / is (что там в гдскрипте я не помню).
А вот onready ты такую проверку сделать не можешь (а она, как видишь нужна).
>Не... "Free to play" - это игра, в которую ты можешь совершенно бесплатно играть
обычно так называют только онлайн игры. Ты конечно можешь продолжать тянуть сову на глобус, но общепринято этот термин связан только с онлайн играми, и синглы с докупаемым контентом с ними никак не связаны
>У них там и мультики, и комиксы, и порнуха (ладно, порнография не официальная, формально "фан-арт").
В твоем странном мировоззрении? Тогда и культ овцы это франшиза, кек
>Я раньше покупал часто для "поддержки разраба", но, на сегодняшний день, видя количество нейрослопа и ассетфлипов, желания поддерживать это уже нет.
Раньше это примерно когда?
>Т.е. пишешь как вор-любитель? Лол... Эх, я бы тебе в подробностях объяснил, в чём ты не прав и как тебе следовало бы работать (с нейронкой), но зачем...
Что мне может обьяснить луддит? Может лучше я тебе расскажу как нейронкой пользоваться? И да, тейк про воровство - ну это смешно. Можешь пойти рассказать авторам холоунайта что они обокрали марио на механику прыжков по платформам
>Тут не поспоришь, но смысл копировать чужие игры, если ты можешь просто в них играть?
Ты даже буквы читать не умеешь, чему ты там меня учить собрался, лудиттище. Копировать != адаптировать. Слово "композиция" тоже по всей видимости тебе неизвестно
>Стим - уже помойка
Это с каких хуев? Любая игра которая пампится в наиболее продаваемые даже за месяц - уже с очень большой вероятностью не говно, просто жанр не твой. В отличии от гп, где алгоритм называется "аукцион", кто больше денег за рекламный лот заплатит - тот и будет выше по выдаче. Даже итч в этом вопросе лучше чем гп
Обновление: я вспомнил, с чего всё началось.
Внимательно читайте содержимое пикрилов.
>>1113247 >>1113248 >>1113251
Ты совсем не о той проблеме думаешь...
Короче, хрен с ним, заглушаю warning.
Правильно делать так, как Годот делает при перетаскивании с контролом.
>Правильно делать так, как Годот делает при перетаскивании с контролом.
=> терпеть отметки "unsafe" на каждой строчке
=> терпеть неверный порядок в автодополнении
=> чувствовать себя идиотом на поводу у движка
Правильно делать так, как лучше работает. То есть "node := $Node as MyType".
Кстати... Читаем документацию:
https://docs.godotengine.org/en/stable/classes/class_node.html#class-node-method-get-node
>Node get_node(path: NodePath)
Этот метод ($/get_node) всегда возвращает Node, т.е. базовый класс в дереве нод, ВСЕГДА.
И что получается дальше?
>var node: MySuperDuperNodeClass = $Node
Здесь неявный кастинг из Node в потомка Node, который не гарантирует результат (unsafe).
>var node := $Node as MySuperDuperNodeClass
Здесь явный кастинг, что говорит парсерсу "я хочу вот этот класс или пошёл нахрен" (safe).
ВЫВОД: Godot был прав, безопаснее будет "$Node as SubClass", а сейчас фигню делают.
> Правильно делать так, как лучше работает. То есть "node := $Node as MyType if $Node is MyType else ReturnNullException()".
>if $Node is MyType else ReturnNullException()
Не надо драматизировать. Движок всё равно упадёт с error, если ты обратишься по null, и в стеке вызовов сразу будет видно, кто виноват и как это можно/нужно решить (добавить if not node: return, конечно).
>Внимательно читайте содержимое пикрилов.
Ой, мне лень в шизе разбираться. Очевидно там была говнопрактика, такое бывает когда разрабатываешь снизу вверх (костыли придумываются над костылями, лишь бы все вместе работало).
Как должен выглядит валидны код каста.
if obj is Dog:
....var myDog = obj as Dog
Но на практике если тебе надо в своем коде кастовать, то ты не маг волшебник, а говнокодя (кроме кастов от дженериков, есть фундаментальные костыли статикодресни).
>Ты совсем не о той проблеме думаешь...
Я тебе показываю архитектуру, где просто нет такой проблемы вообще. То есть, модуль вообще не знает и не ссылает не на какие ноды в дереве сцен. Практика показала что надо вообще минимизировать NodePath в коде (только в "главном" скрипте сцена)
>Движок всё равно упадёт с error,
Играешь в себе игру несколько часов, а она херах упала из-за null. Замечательный подход.
Проблема только в том, что гдскрипте вообще нет обработки ошибок. Безумие задумывалось - что оно либо работает либо нет. Но когда ты пишешь реальный софт, а не демки, детские языки начинают мешать. А ты реально хочешь создать прецедент плавающей ошибки, потому что твоя шиза говорит тебе кастовать в onready.
>Играешь в себе игру несколько часов, а она херах упала из-за null.
Ты сначала разработай эту игру, лалка. Речь о плейтестировании во время разработки - в Release Export движок в принципе не крашится, даже если ты там на ноль будешь 1000 раз в секунду делить, движок будет идти напролом. Проблема только в том, что после внутренней ошибки GDScript отдельная нода со скриптом или все ноды с этим скриптом могут перестать работать - то есть, если у тебя там ошибка в кнопке, кнопка не будет откликаться на нажатие юзером, но движок от этого не упадёт, а только тихонечко насрёт в журнал ошибок в папке user://logs/.
>Безумие задумывалось - что оно либо работает либо нет.
В том-то и дело, что GDScript может "работать наполовину", то есть часть работает, часть - отвалилась. Эта БАЗА.
>А ты реально хочешь создать прецедент плавающей ошибки
Наоборот, избегаю лишних ошибок, возникающих из-за того, что движок кастует не то и не туда (implicit cast).
>>1113401
>if obj is Dog:
>....var myDog = obj as Dog
Обычно я делаю наоборот:
>var dog := obj as Dog
>if dog: print("this is %s dog" % ["my" if dog.user == self else "not my"])
>else: print("it's not a dog at all")
А делать "obj is..." в принципе анти-паттерн. Ты либо делаешь:
>if "make_sound" in obj: obj.make_sound()
И Dog лает, Cat мяукает, Cow мычит и т.д. Либо никак не делаешь.
Иначе будет портянка из десятков классов и это будет очень грязно.
>модуль вообще не знает и не ссылает не на какие ноды в дереве сцен
Ну да, композиция: "да пошла я на хер", и возвращаемся обратно к процедурному программированию...
Ща ща подожди на ним/зиг/хуйсосиг переведем, вот тогда игры делать-то начнем, ухх.
>Ты сначала разработай эту игру, лалка.
Проблемы художников с прокрастинацией.
>Обычно я делаю наоборот
Я видел таких больных на голову, им пофиг на логику или правила/понятия, они там в голове шизу придумают и бьются лбом об это.
Ты спросил, я ответил, как ты воспринимаешь программирование мне не интересно, я не врач.
>Ща ща подожди на ним/зиг/хуйсосиг переведем, вот тогда игры делать-то начнем, ухх.
Зачем когда есть шарпы. GDE это иллюзия гибкости.
>возвращаемся обратно к процедурному программированию
Как у тебя в голове DI привело к процедурному программированию? не отвечай, риторический вопрос
А как ты сделал так, чтобы вся игра не падала с ошибкой? Потому что у меня полностью зависон и выброс ошибки компилятором
Пустил через потоки. Вариант работает.
Остановился в написании своего языка на переборе выходов из функции (return).
>Остановился в написании своего языка
Боюсь спросить - зачем?
Потому что там светит:
- обработка бесконечного количества ошибок для пользователя
- документация
- низкая скорость работы. Возможно, ниже чем в гдскрипте.
- пошли костыли которые я не знаю как решить иначе.
- решил попробовать делать игру, а не свой язык
Ты не ответил зачем.
Я вообще перестал вас вабйкодей понимать.
Стандартная хуйня, кот, яйца, вот это все, лишь бы нихуя дельного не делать. Тут таких каждый второй, причины одна охуительней другой.
В майнкрафте вроде предугадывание действий игрока на шаг сделано.
>программирование мне не интересно
Заметно. Уже и посраться не с кем, одни нейрослоперы...
>>1113409
Там ньюфаг отказывается от дерева, т.е. от ООП в Godot.
>>1113445
>чтобы вся игра не падала с ошибкой
Ты запускаешь "из редактора", а нужно запускать "как игру":
Вариант 1: сделать экспорт проекта (exe/pck).
Вариант 2: запускать через командую строку (cmd):
>Godot_..._win64.exe --path "C:\путь\до\файлов\проекта"
Вариант 3: сделать ярлык (lnk) со следующим:
- поле "объект": путь до Godot_..._win64.exe (editor build сойдёт)
- поле "рабочая папка": путь до папки с project.godot (папка проекта)
- опционально "сменить значок", если будешь часто запускать.
Как там на линуксе не знаю, но должно быть +/- то же самое.
>>1113469
Можно за пару дней написать быстрый ЯП без подводных камней.
https://en.wikipedia.org/wiki/Forth_(programming_language)
https://en.wikipedia.org/wiki/Stack-oriented_programming
Но не нужно, потому что у него не будет богатых библиотек.
>>1113490
>Я вообще перестал вас вабйкодей понимать.
Это из-за нейронок, которыми ты на работе вайбкодишь, вайбкодя.
Я вот его хорошо понимаю, потому что шарю в теме, а не вайбкодю.
>>1113492
>лишь бы нихуя дельного не делать
А ты что предлагаешь, дельный ты наш? Неужели... игры делать???
>дерева, т.е. от ООП в Godot.
Иерархия это фошизм, а горизонтальность свобода, равенство, братство. Почему мразь на программисте думает что должен быть какой-то приоритет между сценами ними? Во многих играх нельзя прям во время игры залезть в стартовые настройки персонажа и перебросить характеристики. Эта сцена с настройками вызывается один раз и жёстко привязана к своему месту. Настоящая левая игра должна позволять менять все в любой момент, ведь персонаж наш флюиден. Тоже самое касается и самой игры!
>Заметно
Как ты цинично вырвал из контекста.
Я вот только не понимаю - это такая постирония или ты реально такой шиз и там тотальная бомбалейла?
>Можно за пару дней написать быстрый ЯП без подводных камней.
Это из серии выучить С++ за 21 день?
А зачем богатые библиотеки игре с персонажем бегающим по клеткам и юзающим везде аттак. Вообще можно даже расширить концепт. Представляете игру как сс13 только все игроки написаны на гдскрипте и нудно пережить смену написав свой код для обработки профессии повара. Вот это игры, а не ваш пресс х ту вин.
С другой стороны это писать код надо, а не ассеты воровать. Тут даже команда нужна.
Я понимаю, что ты троллишь, но всё же:
>дерева, т.е. от ООП
Это разные понятия. Дерево - это такой вид ориентированного графа, где вершина может иметь любое количество исходящих рёбер, но не более одного входящего. ООП - это классы, наследование и инкапсуляция. Иерархию классов в ООП хоть и можно представить в виде дерева, но это всё-таки не одно и то же. Ну да, проект в Годоте выстроен как дерево, но это просто способ упорядочивания равноправных сущностей, всего лишь один из; организовать таким образом можно не только ООПшные объекты, но и что угодно; в свою очередь, ООПшные объекты вовсе не обязательно организовывать в дерево.
Дерево - это просто граф. Так-то.
>Это из серии выучить С++ за 21 день?
Никто не говорил "можно написать свой C++ с компилятором и библиотеками".
Ещё раз: https://en.wikipedia.org/wiki/Stack-oriented_programming
Если не веришь мне, можешь спросить у любой LLM.
>>1113525
>А зачем богатые библиотеки игре с персонажем бегающим по клеткам
Раз не нужны - смело бери и пиши свой FORTH со стеками и на русике:
>НАЧАТЬ
>ЛЕВО ХОДИТЬ
>ПРАВО ХОДИТЬ
>ПОЛ НЮХАТЬ
>ВОНЯЕТ ЕСЛИ
>УБИРАТЬ
>ДАЛЕЕ
>ЗДОРОВЬЕ 0 БОЛЬШЕ ПОКА
Просто, но со вкусом, и ошибиться где-то трудно. Капслок для красоты.
>>1113504
>бомбалейла
С чего там бомбить? С тупого троллинга вайбкоди?
>>1113502
>Иерархия это фошизм
>залезть в стартовые настройки персонажа
>менять все в любой момент, ведь персонаж наш флюиден
Согласен, почему бы и нет:
>class_name Player extends CharacterBody3D
>@export var character_settings_scene: PackedScene
>func _on_feeling_gender_dysphoria() -> void:
>_ add_child(character_settings_scene.instantiate())
Анархия мать порядка, поэтому суём GUI прямо в Player.
>class_name CharacterSettingsMenu extends Control
>func _on_gender_changed(new_gender: Gender) -> void:
>_ get_parent().gender = new_gender
>func _on_menu_closed() -> void:
>_ queue_free()
Проблемы?
>>1113550
>Дерево - это такой вид ориентированного графа
Тот, кто придумал это термин, не видел того, как растут многие деревья (отращивают корни где попало и создают новые стволы и снизу вверх, и сверху вниз, и даже создают боковые соединения между параллельными стволами - жуть!)...
>ООП - это классы, наследование и инкапсуляция
ООП - это объекты. Объекты - это некие сущности, которые могут иметь некие свойства и делать некие вещи, но в остальном это просто "объекты", без каких-то жёстких ограничений. "Классовое ООП", "SOLID" и всё остальное придумали намного позже, но ты не обязан принимать и использовать их так, как оно описано в %популярный_язык_нейм%. Смысл "объектной ориентированности" в том, что ты мыслишь "объектами" и их взаимоотношениями между собой, а не просто жонглируешь данными в переменных с помощью функций - т.е. "объекты" абстрагируют тебя от нюансов железа. Да, ты МОЖЕШЬ использовать дополнительные концепты, например, "классы", которые описывают шаблон для создания новых объектов, и можешь принимать ограничения вроде "объект должен отвечать лишь за что-то одно" (SRP из SOLID) и т.п. Но это не делает эти дополнительные концепты и дополнительные ограничения обязательными для ООП как такового. Единственное, что тебе нужно для ООП - это начать мыслить объектами, а всё остальное опционально.
Возвращаясь к Godot, что такое "сцены" и "ноды"? Ноды - это некие сущности, с некими свойствами и неким поведением. Сцены - это тоже некие сущности, с некими свойствами и неким поведением. Сцены состоят из нод. Сцены также могут состоять из других сцен. Сцены могут состоять из сцен, состоящих из сцен, состоящих... Ну, ты понял. Другими словами, каждая сцена является объектом, а нода является атомарным (неделимым) объектом, из которого состоят другие объекты (как молекулы из атомов или как многоклеточный организм из отдельных клеток). Это на 100% объектно-ориентированная модель, хочешь ты того или нет. Является ли это ООП? Поскольку ты можешь создавать новое поведение комбинированием имеющихся нод БЕЗ написания кода на каком-либо языке (включая GDScript), просто соединяя ноды в дереве сцены и подключая сигналы одних нод к методам других нод, ты можешь программировать, создавая лишь новые сцены (при условии наличия нужных атомных нод). Поэтому язык сцен Godot - это полноценный язык, и он 100% объектно-ориентированный, поэтому дерево сцены в Godot - это ООП, даже если бы не существовало никакого GDScript. Это не уникальная фича Godot, но Godot предоставляет удобнейший интерфейс редактора сцен и достаточно оптимальное ядро, в этом сила Godot.
Чтобы по-настоящему понять то, что я пытаюсь объяснить, нужно смотреть на всё своими глазами, а не верить на слово кому-либо, включая меня. Другими словами, это всё - просто ярлыки. Называешь ты дерево сцены ООП или нет - не важно, его сущность от этого никоим образом не изменится. Твоё восприятие - вот что имеет значение. Если ты читаешь "дерево сцены" и цепляешься к слову "дерево", которое у тебя ассоциируется с "иерархией", "однонаправленностью" и прочим, ты непроизвольно ограничиваешь своё восприятие реальности, и из-за этого можешь не заметить решение задачи, которое лежит на поверхности (не важно, хорошее оно или плохое, сейчас не об этом). Если же ты принимаешь, что ноды и сцены - это объекты, и эти объекты важнее "дерева", чем бы оно ни было, то ты можешь видеть сущность "дерева сцены" и операций с ним с меньшей ограниченностью (ведь слово "объект" ничем не ограничено).
Конечно, для эффективной работы в команде важно, чтобы у всех был одинаковый набор понятий, правил и ограничений. Но пока ты работаешь один (или руководишь другими) - то можешь создать свой собственный набор, более комфортный для решения задач. Поэтому не нужно так сильно цепляться к каким-то понятиям, навязанным окружающими в прошлом.
Ты не знаешь, как избавиться здесь от лишних кастов в гдшарпах?
Есть обработка всех токенов переменных. Токены - это фигня добраная по регекспу. Например - если ты пишешь код variable = 5, то для меня это => name assign number. И вот я их подбираю по коду, чтобы обработать парсером и составить аст древо.
Но есть проблема. Из-за того что мне нужно выделить отдельный интерфейс или класс под это, я должен постоянно кастить. При этом как воспользоваться здесь дженериками, чтобы было без кастов - я не знаю.
Я написал уже весь калькулятор, скоп (запоминание переменных), стейт машину для персонажа из коробки. Остался подбор функций в коде, ифы и циклы.
Что такое стейт машина. Это если вы пишите
состояние стоять:
описание стояния
Если персонаж увидел муху то:
переменить состояние на лежание
состояние лежать:
описание лежания
Тем самым Вы пишите маленькие блоки кода в которых бесконечно вертится персонаж, пока не выйдет от туда вашей же командой. Т.е. стоящий персонаж будет стоять вечно, пока не увидит муху даже не узнав о других блоках кода. А игрок должен писать не многотысячные скрипты, а 5 строк для описания как он стоит и около 10-20 строк для переходов из одного состояния в другое ифами. Как это сделать лучше - не придумал.
Пишем лексер гдскрипта на шарпах в годоте.
Прокрастинация - некст левел.
У годота есть класс, который может исполнить код из строки как "eval". Но зачем если есть хотрелоад?
Обычно быстрее и проще сделать консоль с командами
/add item morkovka
Если же код часть геймплея, то я бы вообще лучше сделал пазлы как в scratch (1). А если это стратегия то постройки-комбинаторы (2)
Для обывателя программерские операторы и выражения не очень удобны. То что тебе кажется очевидным - для обычного человека нудная мутотень с непонятными правилами (будет еще материться почему не работает и что ему нужно)
Скретч все равно так же выполняется. Это дизайн.
То что пользователь матерится - это мелочи. А так с тобой абсолютно согласен. Но этот жанр не полностью изучен. Самое лучшее что видел - Screeps. Но это все для постройки и итерации множества сущностей, а не для одной. Т.е. адекватной ролевки как таковой нет, так бы я сам сидел в неё играл.
>Скретч все равно так же выполняется
Там пазлы позволяют понять что и куда можно прикрепить (и цвета имеют смысл).
Если у тебя игра про автоматизацию и нужно что-то догонять логикой - это значит что в геймдизайне есть просчеты. Обычно логику добавляют как затычку, это отсутствие желания делать что-то готовое (типа на тебе булеву алгебру - япитесь дальше сами).
Не, я о том, что могу накрутить графику, которую потом переведу в текст, которую потом переведу в аст, которую потом экзекютну. И будет графика как в скретче. Так что это не большая проблема, т.к. компиляция выполнится один раз и далее этих шагов происходить не будет. Придется потерпеть лишние пол секунды.
А вот нагрузка на аст ошибками, кастами и ретурном - это огромная проблема, так как может вешать реалтайм.
В общем, в любом случае, собеседование вы прошли, я беру Вас в команду.
>В общем, в любом случае, собеседование вы прошли, я беру Вас в команду.
У меня уже около 11 симуляций/автоматизаций разной степени готовности. Делать их интересно - играть не очень. Ну или нужно умышленно затягивать геймплей, но мне совесть не позволяет, я ощущаю что компенсирую свою несостоятельность в дизайне.
Ну вот как раз для таких пользователей и игра в программиста. Просто написать автоматизацию и проследить как она сработает. По сути - ты ца.
Правда, их довольно мало и шквал критики гигантский, так как каждый из них уже сам пишет свою игру. А значит нужно быть круче всех. Что я, наверное, не потяну.
>Просто написать автоматизацию и проследить как она сработает.
Программисты всю свою жизнь делают автоматизацию. Это не ЦА. Там в хобби делаются куда интересные и сложные вещи. Ты именно ловишь кайф от всяких решений и дизайна (хз как это объяснить, но не один огрызок-язык это не передаст точно). Раньше эта ниша ориентировалась на вкатунцов, мол играешь и учишься, но хайп нейронок отбил желание вкатунцов вкатываться (1).
Зачем мне программисту твой кодинг, когда я беру движок и создаю целые симуляции? То есть, я буквально играю в движок. Так что непонятна кому ты там что делаешь.
>>1113628
>На счет систем, я могу посмотреть и поиграть, если будут под win7.
Не понял о чем ты. В случае меня - у меня там зоопарк демок, каждая состоит из свалок тестовых-сцен. Нет даже меню типа "старт игры" или стартовой локации, потому что "писоть, кушоть, какоть" легче тестировать именно так.
>У меня около 11 симуляций
>>1113629
>Нет меню стартовой локации
Симуляторство уровня /gd/...
>>1113589
>как избавиться от лишних кастов в гдшарпах
>>1113621
>нагрузка на аст ошибками, кастами и ретурном
>проблема, так как может вешать реалтайм
Да ты сначала с базой разберись, прежде чем на оптимизации дрочить. Не всматривался, но если ты дергаёшь Godot-объекты (RefCounted) со стороны #, производительность будет падать в любом случае.
Ты не прав на счёт того, что визуальный язык - это компиляция в текст, потому что визуальный язык технически может исполняться сразу, совсем без конвертации во что-либо, т.к. это особая система.
Сначала: какой цели ты пытаешься достичь? 100% полноценный ЯП для крутых программистов, или игрушечный симулятор для детей/новичков? Язык, заточенный под игру? Игра, заточенная под язык?
Что мешает попробовать FORTH для игры?
Что мешает накидать от балды на GDScript?
Помни: ты не делаешь игру, ты прототипируешь.
Для прототипа совсем не важны оптимизации...
>Что такое стейт машина.
>...в которых бесконечно вертится персонаж
Тебе нужна полноценная машина Тьюринга.
>>У меня около 11 симуляций
>>Нет меню стартовой локации
>Симуляторство уровня /gd/...
Графоман-чел, как же ты плохо разбираешься в реальной разработке.
Каждая сцена тестирует те или иные механики. Когда все механики отлажены, собрать это процедурное говное воедино дело нескольки часов.
В следующей раз когда я буду изменять цепочку производства или систему настроений, я просто запущу нужную автоматическую тест сцену - и сразу увижу сломал ли я что-то или нет (она не только визуально покажет, но и сама состояния сравнит). А ты, когда украдешь мой код реверсом - не сможешь так же быстро писать модули, потому что не будет таких авто-тестов.
Вот и думай.
> какой цели ты пытаешься достичь?
Минималистичного языка программирования, больше декларативного как sql. Где нужно описать просто в стейте, что ты хочешь.
> Что мешает попробовать FORTH для игры?
Потому что не нашел его написанным на c# или гдскрипте, чтобы хотя бы часть списать.
> Что мешает накидать от балды на GDScript?
Уже накидывал. Оно работает, но с недостатками.
Вариант 1. Я беру и пишу аст на гдскрипте - это я делал. Но вышел уродливый код для игрока.
Вариант 2. Использовать сам гдскрипт и парсить логи с ошибками. Работает. Но если вдруг возникают чужие ошибки, то тогда не работает. Нет возможности регулировать процесс, например, остановив выполнение когда игрок применяет действия из кода, а не делать их мгновенно.
>Минималистичного языка программирования, больше декларативного как sql. Где нужно описать просто в стейте, что ты хочешь.
На котлине есть возможность написать DSL язык прям на синтаксисе котлина. Он не прям идеальный, но достаточно хорош, плюс это все еще котлин (не какие-то макросы, это синтаксис языка с поддержкой статической типизацией. DSL со статической типизацией такого вообще нигде нет).
Ну и я кидал видос где кодили на котлине под GDE.
Пикчи пример ответа HTML и CSS.
Я не понял, причем здесь хтмл. Я могу там сделать хотя бы что-то типа такого?
>>1113702
>>Нет даже меню
>плохо разбираешься в реальной разработке
>собрать это воедино дело нескольких часов
Ахаха, ну ты и слоупок, сам себя приложил!
>запущу нужную автоматическую тест сцену
Тебе реально нужно несколько часов, чтобы просто соединить несколько .tscn в одно простейшее меню, содержащее простой список из кнопок? Не шутишь? Проблема-то пустяковая, все ноды уже есть, тебе не требуется изобретать что-то сверх этого для демки.
А я говорил: не привередничай, используй GDScript.
>>1113715
>не нашел его написанным на c# или гдскрипте
Почитай про стековые языки. Это супер-просто, не требуется ничего "списывать" у серьёзных дяденек. Пробовал реализовывать, лично мне понравилось. Применять для игр - возможно... но игроку нужно привыкать к обратной польской нотации.
Могу попробовать накидать на GDScript пример.
>вышел уродливый код для игрока
Эээм... При разработке языка, ты сначала пишешь множество образцов "идеального кода", и дальше стараешься написать интерпретатор к нему.
>декларативного
Тогда ты вообще не с того конца начал, имхо... От императивных декларативные отличаются очень существенно, а именно описывают не то, что ты собираешься сделать, а то, каков результат - и интерпретатор сам ищет способ этого достичь. В ультимативной форме декларативный ЯП == LLM: описываешь результат своими словами, а LLM сама реализовывает все промежуточные шаги.
Императивный язык:
>пока не дошёл до стены: идти налево
>пока не дошёл до стены: идти вверх
Декларативный язык:
>позиция = левый верхний угол
Императивный язык:
>пока жив:
>_ если противник: ударить
>_ если мало здоровья: лечиться
>_ если монетка: подобрать
Декларативный язык:
>игрок = здоров
>враги = мертвы
>денег = много
И т.д. Разница в парадигмах радикальная.
>>1113730
>возможность написать DSL
>прям на синтаксисе котлина
>это все еще котлин
Нафиг ему твой Котлин, если ему нужен свой DSL?
>>1113755
>причем здесь хтмл
HTML - декларативный язык, т.к. он указывает, что необходимо отобразить (кнопка, чекбокс, надпись), не описывая того, как именно это делать (задача конкретной реализации веб-браузера).
HTML - это подмножество более гибкого XML.
Но в твоём случае XML будет избыточен.
Бета 2
>Я не понял, причем здесь хтмл
Ты хотел декларативный язык, я показал декларативный язык у нас дома в императивном.
>Тебе реально нужно несколько часов, чтобы просто соединить несколько .tscn в одно простейшее меню,
Нет, мне надо несколько часов чтобы соединить это все в готовую игру а если ты хороший геймдиз надо еще какое-то начальное повествование сделать чтобы игрока за ручку поводить. Такой вот жанр, ты делаешь игру из тестов.
>Я сегодня фантазировал о своей игре. А вы?
Главное вытерай потом.
>Есть возможность написать DSL с проверкой типов
>Нафиг ему твой Котлин, если ему нужен свой DSL?
Ему нужен DSL, ты говоришь зачем ему DSL.
Я, конечно, понимаю что термин ты только сегодня узнал, но нельзя же буквально в двух предложениях насрать себе в штаны.
Он может на котлине написать свой DSL без написания парсера (это самое утомительное в DSL), плюс DSL еще будет с проверкой типов (случайно паровоз вместо морковки не просунешь).
Ну и да, котлин это лучшая вариация идей питона, в си-синтаксисе, жалко у него нет своего рантайма, не всем по душе JVM мир, хоть там и библиотек херова туча.
Симулировал симуляторов в этом ИТТ треде. Узнали себя?
>>1113792
>соединить это все в готовую игру
Замечательно, так и сделай. Нам ты её, конечно, покажешь?
>ты делаешь игру из тестов
А они весело выглядят, тесты эти? Никогда не играл в тесты...
>Симулировал симуляторов в этом ИТТ треде. Узнали себя?
Попытка в юмор - это защитная реакция на то, что кто-то что-то делает, а ты нет?
>>1113795
>Нам ты её, конечно, покажешь?
Чтобы ты десятилетиями делал те кринж видосы как с демасиком (я даже хз кто это)? Чтобы срал под дверь? И моим знакомым кидал дикпики?
Нет, воздержусь. я и так жалею что спалился на минималистичной векторной графике, ведь ты шиз потом узнаешь мои арты
>Я сегодня фантазировал о своей игре. А вы?
Кстати неплохая задумка на видосе. Не знаю насколько она оригинальная, но будь она в формате небольшой веб-игры, я бы потыкал и пострадал.
Не все же квадратные колеса изобретать, иногда и поездить на них надо.
> Ты либо делаешь:
> >if "make_sound" in obj: obj.make_sound()
> И Dog лает, Cat мяукает, Cow мычит и т.д. Либо никак не делаешь.
А как же мач?
> match obj:
> _ Dog: print("dog bark")
> _ Cat: print("cat meow")
> _ Cow: print("cow moo")
Сначала хотел посетовать, чо мол вот и выросло поколение, а потом выкупил сарказм, выкупил!
>А как же мач?
>>match obj:
>>_ Dog:
А с чего ты взял, что match будет сравнивать классы? В GDScript match сравнивает только значение указанной переменной со значениями всех перечисленных ниже переменных/констант, как "==", только более строго (целочисленный 1 не равен 1.0). Здесь "obj" - это ссылка на экземпляр объекта, а "Dog" - это класс объекта, поэтому они никогда не будут совпадать и match здесь вообще ничего не сделает (выберет "_", если есть). Оператор "is" имеет особое поведение, недоступное для match. Можно, конечно, сделать так:
>var script := object.get_script()
>var obj_class: StringName
>if script: obj_class = script.get_global_name()
>if obj_class.is_empty(): obj_class = object.get_class()
>match obj_class:
>_ &"Dog": ...
>_ &"Cat": ...
Правда, этот код будет правильно работать только с "class_name"-классами в отдельных файлах - у "class" внутри скрипта нет "global_name". Но в любом случае, основная проблема этого подхода в том, что ты создаёшь место в своём коде, которое придётся обновлять при каждом создании нового класса и при некоторых изменениях в уже существующих классах; и, в отличие от редактирования скрипта класса, ты не можешь просто открыть один конкретный файл и найти нужную функцию, а вынужден искать эту if/match-портянку и искать в ней строчку с нужным тебе классом или место, куда можно воткнуть новую строчку. Какое бы ни было поведение, его лучше заправить внутрь конкретных классов и не устраивать if-else-if-else (или match) с классами. Здесь "match" не исправляет фундаментальной проблемы (тугой узел спаггети-кода), а только лишь немного меняет форму записи, которая ни на что не влияет.
>я бы потыкал и пострадал
Там нет управления, оно само едет - симуляция же.
>Не знаю насколько она оригинальная
Ничего оригинального, тыщу раз уже делали подобное.
>>1113804
>защитная реакция на то, что кто-то что-то делает, а ты нет
Я много чего делаю и ещё стараюсь помогать другим (но из-за LLM я стал не нужен)...
>Чтобы ты десятилетиями делал те кринж видосы
Ты путаешь меня с тем толстым троллем. Я, в отличие от него, настоящий шиз на пенсии.
>Чтобы срал под дверь?
Я из дома-то раз в несколько лет выбираюсь, а ты хочешь, чтобы я к тебе в гости пришёл?
>И моим знакомым кидал дикпики?
Никогда не видел смысла в этом.
>жалею что спалился на минималистичной векторной графике, ведь ты шиз потом узнаешь мои арты
Да кому ты нужен со своими рисунками, тем более такой стиль слишком распространён среди инди. И, без обид, но если смотреть на вещи объективно - твоя игра вряд ли выберется из ямы "10 отзывов" в Steam, а на itch.io, Гугл Плей и других площадках твою игру вообще будет не найти. Это не проблема качества и даже не проблема маркетинга, а перенасыщенность рынка - игр так много, что даже если тебе что-то понравилось, но ты потерял ссылку, найти в поисковике пропажу практически невозможно - будут десятки, сотни или даже тысячи похожих по смыслу игр, и перебирать все их нет никакого желания... Вероятность внезапно взлететь и стать очередным инди-хитом ничтожно мала, даже если будешь вкладываться в раскрутку в соцсетях. Тем более ты сам признаёшь, что у тебя "минималистичная" графика, а геймплей слизан с других симуляторов.
Ты должен объективнее смотреть на свой проект, если хочешь заниматься им всерьёз, а не просто по фану что-то лепить. Для примера, то видео с велосипедом с квадратными колёсами достаточно смешное в контексте разработки инди-игр на Godot, но если смотреть объективно, то в Steam такая игра будет непонятной широкой массе игроков и, соответственно, не взлетит - её единственная сила в юморе, который смешит только тех, кто обладает определёнными знаниями. Это признак "нишевости", а это ведёт к "яме 10 отзывов" и забвению на дне рынка. И многие инди-игры страдают от этого - их не понять без контекста, а контекста ни сама игра, ни дополнительные материалы не дают, вот и получается, что люди проходят мимо.
Так что не парься - ты, скорее всего, Неуловимый Джо, как и практически все остальные посетители /gd/.
Алсо, кажется, именно я подтолкнул тебя прийти в раздел /gd/, поддержал твоё желание делать игру-симуляцию и порекомендовал тебе использовать векторную графику в качестве стиля игры. Даже если это был не ты, то как минимум векторную графику я тут часто рекомендовал. Очень обидно, что ты тут только срёшься и даже на меня набрасываешься с агрессией, хотя уж меня-то тут легко узнать (хотя бы не путая с другими местными).
> и match здесь вообще ничего не сделает (выберет "_", если есть)
Да действительно. Перепутал с шарпом, который так может. Ну да ладно.
>Ты путаешь меня с тем толстым троллем.
Да какая разница, публикация тут трафика не принесет, а вот проблем может.
Я вообще понял что фанбазу среди разработчиков ты никогда не найдешь. Как кондитера тошнит от конфет, так и разработчиков воротит от очередных офигительных игр.
>10 отзывов
Уже неплохо.
То сколько я уже слил своих идей и механик, говорит лишь о том что я либо забью болт и ни к чему не приду, либо точно найду изюминку.
>я подтолкнул тебя прийти в раздел /gd/
Это был не я. Просто как-то недолюбливал пиксель арт, но сейчас я немного переосознал эту позицию.
>ты тут только срёшься и даже на меня набрасываешься с агрессией
Я первый редко накидываю, ну или путаю с кем-то и накидываю.
Ищи в редакторе (в разных местах) такие слова:
>linear
>mipmap
>anisotropic
И выбирай опцию, где этих слов побольше. Лол.
Подробнее можешь почитать в Википедии.
>публикация тут трафика не принесет, а вот проблем может.
Постинг в инете в целом может принести проблем. Шизы не только на дваче обитают щас люди в целом более агрессивны стали, а геймерки всегда были
На мой взгляд здесь постить полезно как раз с целью закалить жопу, чтобы на бред реально умственно отсталых адекватно реагировать
>Я вообще понял что фанбазу среди разработчиков ты никогда не найдешь
А ты её здесь искал? Ну лан, правильно что понял
>Это был не я.
Т.е. у тебя нет дневника в /dr/? И это не ты часто про "энтропию", "эскапизм" и прочее подобное тут писал? Сколько вас тут, римворлдо-симуляторов, легион?..
>>1113906
>публикация тут трафика не принесет
Смысл геймдев-форумов в том, чтобы обсуждать с понимающими людьми и поддерживать друг друга, осознавая трудности, через которые мы проходим. Большинство игроков не понимает, через что инди разработчики проходят, и поэтому от них бестолку дожидаться симпатии и сострадания. А здесь, хоть и с подколками и подтролливанием, но люди чаще представляют себе объём труда и страданий.
>Как кондитера тошнит от конфет, так и разработчиков воротит от очередных офигительных игр.
От конфет тошнит рабочего на конвейере, потому что менеджер его специально откормил продукцией этого завода до блевоты (чтоб не воровал), а кондитера - креативного человека с уникальной продукцией - от сладостей тошнить никогда не должно, ибо это его жизненный интерес, он живёт ради сладостей. Так и с разработкой игр: тошнит всяких наёмников у кабанов, кабанов и управляющих кабанов, потому что они тут исключительно ради бабок, а настоящие креативно инвестированные люди всегда рады новым играм и с интересом оценивают чужие игры, даже когда у них собственных игр десятки. И форумы разработчиков, очевидно, располагают ко вторым, а не к первым.
>сколько я уже слил своих идей и механик
>либо точно найду изюминку
С одной стороны ты прав - чтобы сделать правильно, зачастую приходится сначала сделать тысячи раз неправильно. Однако, из любого говна можно сделать конфетку, если упорно работать напильником, срезая неудачное и наращивая нужное. Если ты просто так выбрасываешь "идеи и механики", не анализируя их, то просто топчешься на месте, а не развиваешься...
>Постинг в инете в целом может принести проблем
В инете шизы более скромны чем здесь. Что мотивирует того чела создавать и постить видосики с димасиком? Это конфронтация стала частью его жизни. Ты хочешь заиметь личного ноулайфера и подарить ему стимул - сталкерить по инету и срать под каждым твоим продуктом?
>"энтропию", "эскапизм"
О, это мое, да. Недооцененная тема про энтропию.
Я думал ты про верхний интернет что-то.
>Смысл геймдев-форумов в том, чтобы обсуждать с понимающими людьми и поддерживать друг друга,
Нулевое обсуждение, все сидят и теребят ЧСВ. Все пытаются друг друга принизить, возвышая свою пустую личность.
То есть, вместо решения острых проблемы, люди поносят друг друга своими же проблемами.
Вот ты постебал мечтание о своей игре - а ведь это фундаментально творческая часть любое игродела. Да, у тебя достаточно опыта чтобы перенести игровые плюшки в игру и понять как они там будут - но делать ты уже их не хочешь, потому что это просто момент идеи и дальше ничего не последует. И тебе просто реально в кайф посидеть подумать об этом (помечтать). И это нормально. Но ты же стёбом сам создал прецедент еще одной стигматизации.
Абсурд и то что безыгорка обсирает такую же безыгорку. Деструктива и так в жизни хватает (что снаружи, что и внутри, многие тут с различными формами депрессии) и творческие люди, вместо создания островка созидания, сами же множат деструктив.
>Если ты просто так выбрасываешь "идеи и механики", не анализируя их, то просто топчешься на месте, а не развиваешься...
Ну сначала многие идеи из головы оказались слишком тупыми (несовместимыми). Это по неопытности. В голове оно всегда лучше, даже сейчас с опытом.
Потом оказалось что повторить существующую игру проще чем из креативного геймплея сделать новую. То есть, все устоявшиеся популярные геймплеи игр, это не просто что-то обыденное это самые настоящие паттерны (это я понял когда делал свою 4х стратегию и я буквально пришел к геймплею парадоксов, потому что это лучшее из худших).
То есть, то что кажется поверхностным решением, на деле труд многих дней-недель.
Самое просто что можно сесть и просто делать не думая - это РПГ. Садись и копируй популярное, обрастай жиром геймплея, рисуй/модель месяцами, придумывай истории и персонажей их характер итд. А хочешь дракона? Я дам тебе дракона!
Но нет же я зачем-то делаю игру про зонды фон Неймана и это снова гребанный муравейник, который интересно создавать, но совершенно не интересно играть.
Дроны делают бррррр
>Ты хочешь заиметь личного ноулайфера и подарить ему стимул - сталкерить по инету и срать под каждым твоим продуктом?
Буквально кор фанбаза любой игры. Тот же жопич регулярно ссыт на новые калауты, но все равно играет и даже покупает
Вопрос в правах.
Вот взял я дазовскую модельку импорченную через тул от Diffeomorphic. Сделал из неё лоу поли. Перепёк текстуры. Меня могут взять за жопу за то, что я, формально, спиздил её?
Вопрос такой: А как переодевать 3д перса? Ну, типа, есть у него рубаха, поднимает футболку, тыкает переодеть и меняет шмот на модельке.
Думал отдельными модельками шмот делать, но не совсем допираю, как привязывать.
А зачем ты у мясных мешков спрашиваешь, ты ж обмазался нейронками. Вот там и узнавай теперь.
За мою 40-летнюю дряблую жопу? На вы эстет!
>>1114164
Я спросил, говорит что атата, права один хер принадлежат создателю и риски высоки. Но мне кажется, что дичь какая то. Вот решил уточнить. Может кто интересовался подробнее?
>>1114162
В блендере накидываешь весь шмот на перса, привязываешь к скелету с весами, потом экспортируешь это всё добро. А в годоте уже тупо скрываешь/показываешь куски одежды. Ну либо экспорт модельки конкретной одежды с правильным скелетом, но тут надо уточнить как сделать в годоте так, чтобы один скелет копировал позы другого.
Я совсем новичок в годоте, но по логике как то так.
>В блендере накидываешь
Спс за ответ. Мб ещё, кто ответит. Сам я тоже не профи.
Мне такая же идея пригла в голову, правда я думал брендировать "With soul"
>Вот ты постебал мечтание о своей игре
>стёбом создал прецедент стигматизации
Ты, наверное, слишком серьёзно к этому относишься. Картинка сделана как самоирония: раньше я быстро бросался реализовывать любые идеи; потом начал обсуждать больше, чем реализовывать - с людьми и чатботами, не важно - результатов ноль; а теперь я подмечаю, что мне уже и обсуждать как-то нечего - интересные фантазии об играх бывают, но описывать простым текстом даже не хочется, не говоря о более трудных задачах. Произошла некая самодеградация, однако, по ощущениям всё в точности наоборот. Вот картинка с надписями иронично это описывает.
>>1113965
>совершенно не интересно играть
Тогда не рассматривай это как игру. Почему бы не заниматься "визуализациями"?.. Это как анимация, но создающаяся в реальном времени. Живые обои и т.п. похожим образом делаются. Вот ты запускаешь игру, видишь свой "муравейник", и переключаешься на интересное в интернете, или идёшь кушать, например. Возвращаешься к компу, а там - муравейник сильно разросся, муравьи разделились на партии, каждая - избирает лидера, они что-то не поделили и устроили массовую резню, и чуть не вымерли, но теперь они выживают на руинах старых муравейников. Ты лишь запустил эту "игру", а дальше она сама всё делала и показывает тебе результат - интересный, не так ли? Получается самый чистый образец симуляции, т.к. отсутствует внешний фактор (ввод пользователя). Необязательно заставлять игрока что-то кликать.
Как ты определяешь игру с душой и без? Или это только использования ии касается?
А если допустим через ии буквально передать образ из головы?
>Возвращаешься к компу, а там - муравейник сильно разросся, муравьи разделились на партии, каждая - избирает лидера
Очень быстро хочется перейти к 4х стратегии. Тогда муравей становится не бегающим спрайтом носящий листики, а ресурсом - числом. Ты посылаешь отряд отбивать/добывать ресурс и на следующий день смотришь результат своих разных команд. Туда же и фракции/партии и прочее.
Браузерная 4х стратегия была моя первая идея, но видя как лагают игры парадоксов на компе, идея быстро развеялась (ты не можешь в сетевой игре оставить вычисления в браузере у клиента).
>перейти к 4х стратегии... посылаешь отряд отбивать...
Стоп, но ты же хотел симуляцию? Кого игрок симулирует, главнокомандующего?
>на следующий день смотришь результат своих разных команд
Если игрок замотивирован увидеть результат своих решений - то этот результат лучше всего будет продемонстрировать немедленно, чтобы было крепкое гормональное подкрепление, а не через какое-то неопределённое реальное время. Это база, это фундамент. Вот перед тобой враг, у него щит, а у тебя лук, но ты увидел, что над врагом сталактит висит, выстрелил в сталактит - даже если враг попытался увернуться, он уронил щит и остался беззащитен == игрок победил и доволен, "я сообразил, как победить сложного врага". Если же твоя игра говорит "ты выстрелил - молодец, теперь подожди 24 часа и возвращайся, чтобы узнать исход боя" - это максимально отторгает от игры, особенно если через 24 часа результат может оказаться совсем не в твою пользу (потому что ты опоздал на 0.000001 наносекунды и враг успел поднять щит снова, помножив все усилия на 0). А если ты делаешь так, чтобы игрок не мог проиграть (потратить время ожидания впустую), то ты заранее лишаешь его удовольствия от принятия решения - если любое решение даёт какие-то обязательные награды, то зачем вообще что-то делать? Просто зажми кнопку X и побеждай.
Если ты хочешь стратегию, делай её быстрой. Если хочешь симуляцию, то не заставляй игрока предпринимать какие-то решения для "игры", т.е. интерактивность опциональна. Стратегия - это, например, игра в шахматы, где ходы делаются максимально быстро (у игроков таймер, который принуждает не тянуть с ходом), а симуляция - это, например, настольный фонтанчик с колесиком, которое крутится и симулирует реальный фонтан/водопад/водяную мельницу с миниатюрными фигурками, изображающими людей или животных. В стратегии игрок получает удовольствие от того, что он предпринимает преимущественно правильные решения из общего числа возможных решений, а в симуляции игрок получает удовольствие от, в основном, наблюдения за миниатюрной моделью реального объекта - не важно, физическая эта модель или виртуальная. Ты не можешь превратить симуляцию водяной мельницы в игру-стратегию, потому что тогда это будет очень плохая стратегия или очень плохая симуляция. Выбери что-то одно и делай это как положено.
Честно говоря, раздражает этот показной маркетинг "NO AI" - во-первых, если бы ты делал с сильным использованием "Generative AI", этот слоп было бы видно за версту и без этикеток; во-вторых, тот факт, что ты не использовал "Generative AI", не гарантирует того, что твоя поделка не является бездушным слопом от личинки кабанчика-ассетфлипера, которая захотела постричь бабла на детях/лохах и подстраивается под условия рынка. Всё это очень напоминает всратый маркетинг продуктов "без ГМО", "без глютена", "без сахара", "без мяса", "без красителей", "без консерваторов" и т.д. Зачем вы эту ненужную информацию лепите прямо на обложку? Это же просто дебильнейший маркетинговый ход, только идиот поведётся на это. Если человеку ВДРУГ нужен продукт без чего-то, он может ПРОСТО посмотреть "состав", который производителей по закону ОБЯЗЫВАЮТ честно писать на обратной стороне этикетки. И если там чего-то нет, то в продукте этого чего-то нет. Точка. Иначе можно было бы создать гигантский список "чего тут нет", и перекрыть этим списком вообще всю упаковку, чтобы человек не мог увидеть и понять, что же там вообще ЕСТЬ (ради чего покупатели покупают и/или скачивают продукт)...
Короче, на лоб себе налепи наклейку "NO BRAIN - NO PAIN" или что там у тебя. Шучу, не надо.
>>1114272
>брендировать "With soul"
Меня как атеиста бесит это, но не вижу более ёмкого синонима... Может, "deeply meaningful"?
>>1114314
>Как ты определяешь игру с душой и без?
Не нашёл определения на русском, вот на английском от LLM (DuckDuckGo):
>In the context of products, "soul" refers to the deeper meaning or emotional significance that consumers perceive in an object, which can greatly influence its value and appeal. Marketers often use storytelling to craft this "soul" to enhance consumer connection and engagement with the product.
Короче - если у игры только красивый фантик и ровно ноль смысла внутри, то это "бездушная" корпоративная или ассетфлиперская подделка под игру. Если игра сос мыслом - то это "игра с душой", даже если фантик недостаточно красивый и внутри куча багов. К Generative AI данное определение никак не касается, потому что сгенерированный контент может иметь какой-то смысл, но вот беда - генеративный контент чаще всего используют кабаны-ассетфлиперы, для которых игры - это средство заработка (красивый фантик), а всё остальное им не важно.
>А если допустим через ии буквально передать образ из головы?
С текущими "Generative AI"-моделями это КРАЙНЕ сложно, не намного проще каких-либо иных инструментов, нужен реальный скилл, который невозможно получить простым промптингом, и зачастую нужны какие-то специфические инструменты и умение ими ловко пользоваться. Если у тебя "легко" получается реализовать "образ из головы" через Generative AI - скорее всего, ты просто привык к тому, чем тебя кормят нейронки, и просто предвкушаешь очередную порцию нейрослопа, а не хочешь чего-то конкретного. Если же у тебя реально был какой-то замысел, и ты делал усилия, чтобы добиться именно его - то тут не важно, GenAI или не GenAI, главное, что желаемое достигнуто и это желаемое несёт в себе чёткий смысл, а не просто фантик для маркетинга. На этом срезаются многие "геймдевы", потому что хотят они не игры, а деньги, и поэтому делают "бездушный" слоп - не важно, руками, ногами, фрилансерами, нейронками и т.д. Потоки слопа на геймерских площадках из-за того, что многие рукожопые кабанчики подскочили за деньгами - вернее, за мечтой о легкодоступных деньгах, которые они рассчитывают получить от публикации очередной порции слопа (и смешно визжат, когда им говорят, что их слоп не нужен).
TL;DR: наклейка "NO AI" или "with soul" - это клеймо кабана-ассетфлипера и бездушного слопа (но бывают исключения), пропихиваемого в глотку потребителя ради копейки, о которой так мечтает кабанчик, который метнулся сначала к GenAI, потом взвизгнул и метнулся обратно, лишь бы не потерять эти сраные копейки прибыли. А суть одна - если делаешь игру только ради денег, то делаешь говно в красивом фантике. Доказано десятками ААА студий и сотнями тысяч "инди".
>TL;DR: наклейка "NO AI" или "with soul" - это клеймо кабана-ассетфлипера и бездушного слопа (но бывают исключения)
Ну вот да, тоже хотел подвести в итоге к ассетфлиперам, и то что даже если где-то использовался ручной труд, он не гарантирует "душу" которую чтобы разглядеть, нужно иметь хоть сколько то общий опыт с автором, в противном случае назовут долбаебом а игру [нейм]слопом
>С текущими "Generative AI"-моделями это КРАЙНЕ сложно, не намного проще каких-либо иных инструментов
Ну не знаю, мне все таки кажется что всё упирается в количество токенов и зависимость игры от нейронки, но если грубо говоря конкретно формулировать промпты и пошагово прописывать механики, то постепенно можно собрать близкий к мысленному образ, даже с текущим уровнем ии. Но поддерживать потом самостоятельно и расширять это говно не сможешь
>Перепись чсвных душнил
Ты же обещал не возвращаться. Как дела?
>Вот ваше-то мнение самое правильное
А твоё мнение заключается, конечно, в
>вы все - чсвные душнилы, а я - д'Артаньян
Я полагаю? Очень интересное мнение.
>>1114379
>чтобы разглядеть, нужно иметь хоть сколько то общий опыт с автором
Ну, почувствовать наличие глубокого смысла в игре можно даже без понимания этого смысла и сопереживания автору и персонажам. Это как слышать речь на чужом языке - ты можешь уловить сложность фраз, не понимая их смысла, просто оценивая относительную сложность паттернов. У "нейрослопа" обычно очень простые, часто повторяющиеся паттерны, которые нейросеть смогла извлечь из огромного датасета путём усреднения наиболее часто встречающихся паттернов. С развитием генеративного ИИ эти паттерны усложняются, но суть не меняется - это "средняя температура по больнице", как будто ты смотришь в "общее сновидение всего человечества". Интересное явление, на самом деле, но для реально осмысленной игры вряд ли подходит. У ассетфлипов та же проблема - они берут наиболее популярные паттерны из легкодоступных (бесплатные или дешёвые ассеты) и лепят из них нечто очень поверхностное, шаблонное.
>упирается в количество токенов
Если аргументировать "количеством X", то можно свести любую технологию к брутфорсу: "этот взломщик архивов невероятно хорош, просто ему нужно в триллион раз больше попыток, чем вы пробовали, чтобы вскрыть архив - какие-то 150 лет и ваш архив будет расшифрован, вот увидите". Маркетологи впаривают GenAI как "умную волшебную палочку", а не как "тупой брутфорс", нет? В конце концов, если бы "Искусственный Интеллект" имел более высокий интеллект, то он мог бы решить множество проблем за меньшее количество шагов/токенов/итераций продукта - уровень интеллекта измеряется в том, насколько эффективнее процесс по сравнению с брутфорсом (т.е. случайным/грубым перебором всех возможных вариантов, пока не наткнёшься на решение).
>если конкретно формулировать промпты и пошагово прописывать механики
Это всё-таки большой объём работ, требующий очень много итераций: описал что-то -> получил играбельный прототип -> поиграл и проанализировал -> понял ошибки -> исправил -> поиграл... С нейронками эта задача усложняется тем, что их "правки" зачастую даже хуже "неисправленного". Поэтому правильная разработка игры выглядит контр-продуктивной для типичного вайбкодера: зачем вайбкодеру вносить какие-то правки в его "продукт", если этот "продукт" работает (то есть запускается и не падает с ошибками) и может быть опубликован и куплен игроком в магазине? Необходимо иметь очень большую силу воли, чтобы сказать "нет, это говно" и переделать всё. Вот когда ИИ сможет сам играть в игры (в смысле переживаний, а не в смысле достижения целей в заданном наборе правил игры), субъективно оценивать переживания целевого игрока и потом вносить необходимые правки, тогда ты сможешь расслабиться и заказывать себе игры у этого ИИ. Правда, это будет уже совсем другая эпоха, с другими условиями жизни...
Я скептически отношусь к GenAI в геймдеве, потому что техническая реализация каких-то игровых механик и даже создание графики никогда не были главной проблемой. Да, долго, да, для этого нужны какие-то знания и навыки, но даже с минимальными знаниями и навыками вот уже 25+ лет можно делать полноценные игры не хуже ААА, только в меньшем объёме - достаточно знать, что множество "инди-хитов" сделаны необразованными самоучками в подвале. Что дал GenAI? Тонны ассето-слопа и скрипто-слопа, которые можно делать очень быстро, но... зачем? В реале у нас давно стали популярны "фастфуд-рестораны", которые позиционируются как более "быстрые", чем классические, но эта скорость не должна компрометировать качество. Никто не хочет идти в ресторан за центнером отходов кухни, покупаемых за копейки. В ресторан приходят за вкусной и питательной пищей в минимально необходимом объёме, а не чтобы залить полный бак помоев. Так и с играми: что толку от всех этих ассетов и всего этого кода, если всё это смешивается в какие-то непонятные потоки помоев? Пусть бы ты потратил в 10, в 100 раз больше времени - но если бы ты сделал хорошо, всё это время имело бы смысл. А так ты тратишь в 100 раз меньше времени, делая какой-то ненужный слоп, на который и секунды не хочется тратить. Зачем?..
Вот простой пример: тебе нужно заполнить локацию какими-то декоративными контейнерами, которые не несут функциональной роли, а просто для создания ощущения, что игрок попал на какой-нибудь склад. В прошлом, как в ААА, так и в инди-сцене, было принято делать 1 или 2 контейнера и потом дублировать их по всей сцене раз 10 или 100, чтобы не тратить время на бесполезную работу, которую никто не оценит. Но эти 1 или 2 контейнера сделаны красиво, вписываются в сцену и имеют разные стенки, чтобы можно было повернуть по-разному и они выглядели неодинаковыми. Сегодня приходит вайбкодер с типичными "гениальными" идеями вчерашнего малолетнего игрока и думает: "раньше дублировали контейнеры, потому это было трудозатратно, а уж с GenAI я бесплатно нагенерю 1000 уникальных контейнеров за один вечер". Что в результате? Да, контейнеров в сцене реально 1000 и реально каждый из них "уникален" (в техническом плане - пиксели разных цветов), но... сцена ощущается какой-то шум или грязь - смешанная куча непонятно чего. И вес игры раздулся на +100 ГБ, а это одни только коробки. Вайбкодер, конечно, начнёт оправдываться, что "так и задумано", "купите более мощный компьютер", "зато не потратил ни копейки ни на один из этих 1000 ящиков", "зато я не умею ни рисовать, ни моделировать, а у меня аж 1000 ящиков" и т.д. Но по факту мы имеем не игру, а цифровые помои - крайне низкое качество в огромном количестве, без смысла и цели, лишь бы заполнить цифровое пространство чем-то отдалённо напоминающим хорошую работу. Этого ли мы хотели, когда хотели разрабатывать игры? Нужно ли нам делать 1000 уникальных ящиков за один вечер без знаний и навыков? Что плохого в том, чтобы сделать один хороший ящик за тот же вечер после пары месяцев обучения и получить хорошо выглядящую, компактную на диске сцену? Станет ли вайбкодер идти путём "дедов" и генерировать 1, но красивый, ящик за те секунды, что необходимы нейронке для генерации, и не пытаться залить всё потоком помоев? А сможет ли нейронка с первой попытки прочитать мысли вайбкодера и не заставить его выбирать 1 лучший ящик из 1000 сгенерированных, потому что с первой попытки всегда получается какой-то слоп?
По сути, главная проблема "GenAI" не в технологии, а в её пользователях. Рано или поздно ИИ встанет на один уровень с человеком, но это будут уже не ИИ, а новые люди. Но до той поры мы раздали необразованным обезьянам скоростные гранатомёты с бесконечным запасом ядерных гранат с самонаведением на любую цель и теперь наблюдаем цифровой апокалипсис, потому что... стоит ли объяснять, почему неразумно раздавать обезьянам гранаты?
>Как ты определяешь игру с душой и без?
Я не собираюсь, это просто маркировка, которая может показать отношение разработчиков. В то время пока Тим Свинья пытается запретить марикировать АИ игры, можно поймти и от обратного.
>>1114374
>Меня как атеиста бесит это
Значит это даже лучше, чем я думал.
>>1114374
>TL;DR: наклейка "NO AI" или "with soul" - это клеймо кабана-ассетфлипера и бездушного слопа
Ты и сути не понял и пердак подорвал.
Знатно слопперы пригорели от идеи ввести марикировку игр от людей, конечно, удивительно даже, вроде карман им не тянет, но нет, картинка им уже мешает.
>>1114403 (OP)
>>1114403 (OP)
>>1114403 (OP)