Шапка: https://hipolink.me/godothread
Предыдущий: >>1063666 (OP)
Архивный: >>1059249 (OP)
Теперь хочется типизированные каллабли и типизированные сигналы. Но пока во всех обсуждениях не могут с синтаксисом определиться, а уж вписать в движок даже и не пытались.
>Теперь хочется
Вот бы еще какую-то аналогию Start() который бы вызывался по дереву вниз после всех _ready(). Чтобы можно было код по человечески организовать. А не костылить
await get_parent().ready
await get_tree().root.ready
зато у нас есть бестолковый @onready код красивое
поныл
>Вот бы еще какую-то аналогию Start() который бы вызывался по дереву вниз после всех _ready()
У тебя чет с архитектурой не то, если тебе нужно в потомках ждать когда очнется их родитель
Ну не все же художники, которых устраивает мешанина из вызовов get_node(), многие возможно захотят переиспользовать некоторый код в других проектах, или даже написать юнит тесты (тут еще и данамический язык, грех не писать). Но никто не хочет писать целый сервис по инжектам, достаточно было бы если родительская нода (чаще сабсцена) занималась инстанцированием для потомков, а потомки дергали её переменные-внешние зависимости (чтобы не пропихивать в каждую ноду руками инжекты, тоже боейлерплейт).
Преимущество
-Ты видишь всегда все зависимости для сабсцены.
-Меняешь все зависимости для сабсцены только в одном месте (например в один клик поменял целую сетку тайлов, а не бегая по коду собирая все зависимости).
Есть конечно приоритеты, но кто будет в здравом уме и руками каждый раз менять?
Вариант (костыль) с await node.ready - вроде сохраняет порядок (я очень надеюсь). Поэтому это возможно решение.
В юнити почему-то такое есть, наверное там пишут сложные игры?
>Меняешь все зависимости для сабсцены только в одном месте (например в один клик поменял целую сетку тайлов, а не бегая по коду собирая все зависимости).
Это перегиб в одну сторону, которая тоже может отравить жизнь, когда зависимость по любой причине придется раздробить. Так что дело не в художниках. Call down, signal up - какой бы говниной не был всяко лучше подобной лапшичной, при этом проблемы с переиспользованием у этого подхода не хуже и не лучше твоих. А у тебя потомки зачем-то лезут в родителя.
Проблемы начинаются если в родительской сцене есть код инициализации (логика) в _ready (тебе движок насует null'ов для потомков).
>когда зависимость по любой причине придется раздробить.
Что за бред, мы как раз и занимаемся унификацией зависимости.
> А у тебя потомки зачем-то лезут в родителя.
Это упрощенное IoC, они не лезут в потомка, а спрашивают инстанс. Тоже самое если бы я инстансы руками в них прокидывал (так правильнее).
dependency3 = ExternalDependency.new()
dependency3.setup(global_posiont, flag)
child_1.setup(dependency1, dependency2, dependency3)
child_2.setup(dependency3)
Но, только чтобы такой чепухой не заниматься, дети сразу опрашивают ссылки заготовленные ссылки.
По честному, тут не должно быть детей, но сцена всегда родитель и не хочется создавать отдельную инстанс-ноду только для таких вот вещей.
Я не хочу объяснять основы IoC и DI я просто поныл
>Что за бред, мы как раз и занимаемся унификацией зависимости.
Ну а если на данном этапе зависимость должна перестать быть унифицированной для одного конкретного типа потомка? По любой причине. В call down эта проблема решается очень просто и в одном месте, в твоем же случае либо придется делать дублера в родителе либо редактировать всех потомков.
>Ну а если на данном этапе зависимость должна перестать быть унифицированной
Что значит перестать быть унифицированной?
Вот есть
parent.tileMapLayer - мы его получили из вне.
parent.astar - пускай мы вычислили кэш тут прям в родителе (сам класс тоже извне).
все потомки этой сцены всегда ссылаются на родительский parent.tileMapLayer и parent.astar
Как если бы я их явно передал через IoC:
child.setup(parent.tileMapLayer, parent.astar)
Если я перемещу эту сцену в другой проект, я увижу что для сцены мне надо реализовать
parent.tileMapLayer
parent.astar
И все заработает.
Для тестов достаточно будет замокать эти объекты (Это не так удобнее будет как с чистым DI, но тоже достижимо).
Конечно, без интерфейсов придется лезть в кишки и смотреть какие методы мокать, но на то они и тесты.
>>1066914
>По честному, тут не должно быть детей, но сцена всегда родитель и не хочется создавать отдельную инстанс-ноду только для таких вот вещей.
Это, кстати, не работало бы (как только добавляем сабноду, проблема возвращается)
Это значит что ты получаешь ссылку на родителя чтобы что-то с ней сделать, ну например вызвать метод или получить переменную. Но что если у тебя появится потомок, которому нужна определенная расшареная переменная, но не в том виде в котором она представлена (переменная должна быть засунута в обьект, либо должна пересчитываться чаще чем она же но для других потомков) - и нужно либо вводить дублера зависимости с требуемым функционалом, либо нужно редактировать саму зависимость (а равно и зависимых от нее потомков). Классическая проблема рефакторинга.
>Call down, signal up - какой бы говниной не был всяко лучше подобной лапшичной
Решение проблем зависимостей через сигналы, я даже боюсь представить. Есть ссылка? Там только какой-то пост на редите гуглиться, но они уже обсуждают сам подход (как и другие ссылки). Это же не через синглетон и шину AND HIS NAME IS JOHN CENA!!!!!!!!!!!!!!!!!!!!
?
PS Не лучше ли оставить сигналы (ивенты) для того чего они были созданы (не в умах разработчиков годота). Я немного стал понимать тех людей, которые пишут свои движки, как можно было пройти эволюция IoC 20 лет назад?
> Но что если у тебя появится потомок, которому нужна определенная расшареная переменная
Сделать её. Иснтансер (родитель) отвечает за все инстанцы, какие бы они сложные не были.
Мы одной сцене, это нормально что все участники модуля сцены знают друг о друге. Проблема в соединение таких модулей сцен.
Пикча очернела.
Представьте, где-то в параллельной вселенной есть игровой движок на базе Spring Framework
>Решение проблем зависимостей через сигналы, я даже боюсь представить. Есть ссылка?
Ссылка на то как работают сигналы?
>как можно было пройти эволюция IoC
Как будто ioc святой сам по себе
>>1066924
>Сделать её.* продублировать ее и функционал для нее
Понял тебя.
>Проблема в соединение таких модулей сцен.
Если потомком полностью владеет его владелец, определяет все его внешние состояния кроме его внутренних состояний - никакой проблемы не будет, переносимость не страдает, потому что даже в твоей схеме потомок тупо не поднимается если у него нет нужной родительской зависимости, в моем же случае - потомок равнозначно недееспособен, пока родитель его не пнет сам. При этом сигналы нужны, только если потомок захочет чтобы родитель или родитель родителя сделал какое-то действие, соответственно мне не нужно перебирать зависимости руками, за меня это делает дерево и потребители моего сигнала.
>Ссылка на то как работают сигналы?
Я думал это какой-то паттерн на сигналах.
>Как будто ioc святой сам по себе
Что может быть лучше парадигмы "чистой функции"?
В костёр еретика!!
>Понял тебя.
Я тебя не понял.
Пример приведи, я же не телепат. IoC решает все проблемы зависимостей, попутно отделяя от глобального состояния.
>>1066927
>потомок потомок
Каша в голове. У нас есть модули и связь между модулями.
Пускай модулем будет сцена.
1) Связь с внешним миром и инстанцирование всегда через через один узел (похер родитель он или нет - только одна точка входа)
2) Связь внутри модуля между собой похер какая, хоть $грин ссылками.
Просто перемести сцену из одного проекта в другой и пойми в чем проблема.
Я сложнее систем тырпрайзной джавы нигде не встречал, люди через боль пришли к Spring, который на самом деле изначально был просто DI контейнером.
Так что да IoC способен решать проблемы сложных систем (жабисты открыли для себя, по сути, силу чистых функций)
https://github.com/godotengine/godot-docs/issues/8478
>Пикча очернела.
Лол, ночная версия
>>1066911
>Call down, signal up - какой бы говниной не был
Кто-то где-то говорил, что это говнина?
>>1066906
>Вот бы еще какую-то аналогию Start() который бы вызывался по дереву вниз после всех _ready().
Допустим, ты добавляешь ветку размером более трёх этажей иерархии. После _ready на втором этаже на первом должен происходить Start? Или только когда стартанёт третий этаж? Или оба раза?
В первом случае возможны аналогичные проблемы с бабушками-дедушками. Во втором раздувание очереди вызовов на больших деревьях. В третьем избыточное количество этих самых вызовов. Кароч со стороны дерева это лишнее.
Но вот если всё-таки надо детей дёрнуть после родителя. Ну вот надо мам. Что навскидку приходит в голову.
1. В _ready родителя пройтись по детям. Собственно, это так и задумывалось, _ready гарантирует, что все дети уже готовы к опросу. А дальше утиная типизация.
for child in get_children():
_ if child.has_method("start"):
_ _ child.start()
Согласуется с концепцией CDSU, кстати.
2. Подписать детей на сигнал ready у родителя. Уже обсуждено.
Хотя это по сути противоположность CDSU, но тоже является легитимным подходом, не зря ж этот сигнал добавили.
3. В первом кадре _process или _physics_process (они вызываются только в готовой ноде в дереве) потыкать палочкой родителя и, если он готов, единожды вызвать у себя Start и запомнить этот факт. Лютое индусство. Но рабочее. Имеет смысл, когда важен порядок, потому что во-первых можно регулировать приоритет, во-вторых внутри одного приоритета вызовы идут строго по порядку снизу вверх (в том числе внутри одного уровня иерархии).
>>1066922
>потомок, которому нужна определенная расшареная переменная, но не в том виде в котором она представлена (переменная должна быть засунута в обьект, либо должна пересчитываться чаще чем она же но для других потомков
Чивоблять. Расшаренная переменная одна для всех. Если не хватает - расшарь больше. Если только кому-то одному нужны какие-то особенные данные, пусть у себя их хранит. Если надо получить данные из общей переменной и перевести в определённый вид - пусть сам конвертит. Если надо чаще пересчитывать, пусть сам пересчитывает. Расшаренная должна быть минимальной - только то, что надо действительно всем.
>Никакой проблемы, совершенно,
Просто сцена никак не работает и фиг знает что с этим делать.
>Допустим, ты добавляешь ветку размером более трёх этажей иерархии. После _ready на втором этаже на первом должен происходить Start? Или только когда стартанёт третий этаж? Или оба раза?
Там как работает
1) создаются ноды, потом:
2) _ready() подымается вверх по дереву (до рута)
3) Добавить чтобы _start() опускается вниз по дереву.
Те кому родителе не важен, а важны потомки делают дела в _ready
Те кому родитель важен (и потомки) делают дела в _start
> В _ready родителя пройтись по детям
Лишний бойлерплейт, тем более дети могут быть динамичными - то приходить то уходить.
>2. Подписать детей на сигнал ready у родителя. Уже обсуждено.
Да это рабочий вариант, await сохраняет порядок. Вроде должны были доку эту инфу добавить, но я не нашел. Надеюсь не поменяют поведение в версии.
Но там инстансы без логики, поэтому отстрелить себе сложно будет.
>3. В первом кадре _process или _physics_process
Думал, грязновато, но нашел лучше решение.
Так же думал с _enter_tree(), это тут немного другое.
Нет, мне редактор высрет ошибки с налл-поинтерами и я пойду их решу (ну или игра при запуске крякнет с той же проблемой).
Ошибки это же помощники программиста, они сообщают что что-то не так (и где).
Так же я сразу вижу, какие нужны данные/сервисы чтобы эта сцена работала (без запуска).
>которая формируется хуй пойми как.
Вот простой пример. Я специально делаю @onreаdy чтобы визуализировать зависимости (в этом нет необходимости, просто наглядно).
Даже подписала для тебя :3
Молодец что подписал, но проблемность архитектуры от этого никуда не делась, я написал уже практически все что хотел об этом (и даже больше чем надо бы), в общем - дрочи как хочешь, продолжать дискуссию я не буду, можешь засчитывать слив.
>можешь засчитывать слив.
Да всем пох.
Я пытаюсь найти гибкую систему, так как постоянно прыгаю по проектам.
Вот, например, агрегация идет нахер (как и наследование), в языке же нет неймспейсов. Придется использовать ноды и забыть про автокомплит. Или писать очень длинные имена.
UnitService_DamageService_СubicDamageAlgorithm().new()
Если ты про uid, то нет, их сдизайнили так чтобы ты ты если надо переносил оба файла в другое место (да, ебануто)
Я всегда импульсивен и графоманю. Я туплю и ошибаюсь как и все, тем более геймдев для меня новое. Иногда в споре рождается интересная мысль, но в целом уже не тот возраст чтобы самоутверждаться "в чатиках". Я больше хотел донести идею, чем то что я прав или не прав (кому не пофиг на анонимном форуме).
И не факт что идея работоспособна и не придется опять все переписывать (но пока мне нравится, как-будто мне вернули мой 2005 и я сижу с костыльным полу-контейнером собранным на коленке).
>uid
Там еще .import
Не критично, но зачем им тогда папка /.godot, обычна вся "мета" там.
.godot - твоя личная папка твоего компа
если ты даёшь проект кому то другому, то ему надо сказать а как этот файл импортировал ты чтобы на его ПК он так же импортировался
Из скрипта в физикс_процессе я сдвигаю noise.offset.x += delta * 10. Сначала всё нормально, но после примерно 300 картинка начинает мерцать: быстро, но заметно для глаза становится то темнее, то светлее, но при этом не очень сильно.
Пробую без шейдера, просто натягиваю шумовую текстуру на спрайт и двигаю оффсет в ней. Ничего не мерцает.
Меняю любые параметры шейдера, но не меняю оффсет. Не мерцает.
Задаю изначально оффсет 400. Не мерцает.
Загадочно. И не оч понятно как такое дебагать. Тем более что этот оффсет - это даже не параметр шейдера, это параметр шумовой текстуры, которая потом отдаётся шейдеру. И кроме мерцания визуально не вижу никаких изменений в ней.
Прикрепить видео не могу - кодек сильно шакалит, потому что картинка по сути шум.
Ну допустим текстуре надо поставить repeat в шейдере, хз, так пальцем в попу небо
> (да, ебануто)
Ничего ебанутого. В 1СБухгалтери тоже так. Вместе с базой генерируется GUID и хранится в текстовом файлике вместе с базой. Очень удобно. Хорошо что в Аргентине тоже понимают плюсы русской бухгалтерии.
Достаточно было сделать папку /.meta в каждой папке где есть ресурсы. При копирование папки автоматически копировалась бы вся информация.
Все равно нужен инструмент который следит за изменениями (редактор годота следит, а скажем, какой-то vscode без плагина, нет)
С базой данной тут другое, тут ты ее реально захочешь перемещать для бэкапа (хотя базы рекомендуют снимать дамп в sql, хз как там в 1С).
>мета информацию
Это всего лишь уникальный идентификатор. Если они тебе мешают - настрой скрытие uid-файлов в том редакторе, который ты зачем-то используешь для просмотра списка файлов (в Godot они и так скрыты).
>>1066955
>переносил оба файла в другое место (да, ебануто)
>>1066997
>Достаточно было сделать папку /.meta в каждой папке
Смысл нахождения файлов .uid/.import рядом с оригинальным файлом в том, чтобы можно было быстро переместить всего один оригинальный файл со связанными с ним .uid/.import из одной папки в другую даже через внешний редактор (как Explorer в Windows), не ковыряясь ни в каких скрытых "/.meta", "./godot" и т.д. Также это позволяет иметь множество одноимённых файлов без лишних коллизий метаданных.
Задача: переместить файл "game/scripts/thing.gd" и "game/textures/thing.png" в папку "game/thing".
Как это решается сейчас:
1. Открыть два окна Explorer: "scripts" и "thing".
2. Выделить файлы "thing.gd" и "thing.uid" в "scripts" и переместить их в "thing".
3. В первом окне перейти в папку "textures".
4. Выделить файлы "thing.png" и "thing.import" в "textures" и переместить их в "thing".
Всё. Проект должен открыться и работать без проблем.
Как ты/вы предлагаете:
1. Открыть два окна Explorer: "scripts" и "thing".
2. Выделить файл "thing.gd" в "scripts" и переместить в "thing".
3. В первом окне перейти в папку "scripts/.meta", а во втором окне в "thing/.meta".
4. Выделить файл "thing.meta" в "scripts/.meta" и переместить в "thing/.meta".
5. В первом окне перейти в папку "textures", а во втором окне в "thing".
6. Выделить файл "thing.png" в "textures" и переместить в "thing".
7. В первом окне перейти в папку "textures/.meta", а во втором окне в "thing/.meta".
8. Выделить файл "thing.meta" в "textures/.meta" и переместить в "thing/.meta"...
...ай, thing.meta одного файла перезаписала thing.meta другого и всё сломалось.
Но даже если бы не сломалось - шагов получается раза в 2 больше. Но зачем?
Я нередко вижу, что люди организовывают сцены в отдельной папки со всем содержимом
res://entry/unit/MyUnit/
res://entry/service/Camera2D/
res://world/test/FirstWorld/
(противовес юнити, где каждый ресурс в своей ерирахии папок папке)
В этом случае, когда ты хочешь переместить всего юнита, ты копируешь всю папку и хочешь всю мета-информацию переместить вмести с ним.
Но когда ты хочешь вытащить скрипт или картинку, ты именно хочешь вытащить ее отдельно и добавить как новый ресурс в новом проекте (тебе мета не нужна).
Просто надо было сделать стайл-гайд по организации и сделать мета-папки.
Я не помню в каком софте такое видел, но где-то было.
Конечно не называть это "/.meta" а так же "/.godot" или "/.godot-res"
Не то чтобы это критично, но во всех "редакторах" не настроишь. Я как TC открываю, как проводником, (или проводником редакторе) и чувствуется задержка восприятия (приходится придавать больше усилий чем обычно) или иногда миссклик если не всматриваешься в это.
> Как ты/вы предлагаете:
В файле thing.gd в первой строке написано:
> # UID string: bab1e5face8d
> Don't remove UID string, please refer documentation ...
Вот как предлагаю я. Кроме предложения плизрефернуться, эти строки ещё и прячутся от меня во встроенном редакторе, увидеть их я смогу только если юзаю внешний редактор.
Юзеры при копипасте кода будут случайно это таскать.
Хватит того что табы слетают иногда тут еще будет магическая ошибка в которой юзер вообще не разберётся.
Там некоторые пулреквесты с 2019 года (про вчерашний _start()), я думаю нет смысла вообще обсуждать, там художники и они так видят.
> при копипасте кода будут случайно это таскать
Если юзер достаточно прошаренный, что его не устраивает встроенный редактор, в котором эти строки скрыты, и он юзает внешний редактор, то он догадается, что это метаданные, и их желательно не таскать. В противном случае - его проблемы. Он был предупреждён.
Человеческий фактор (мастхев в инженерии). Если об "это" можно удариться головой - кто-то, когда-то непременно это сделает. И лишь вопрос времени, когда ты сам.
Это вообще базис языкосрача, когда не язык плохой, а программисты плохие, неправильно используют что-то.
Как я уже писал в прошлом треде, моя точка зрения опирается на унификацию: все ресурсы содержат в себе синтаксически прописанное поле с идентификатором, поэтому и скрипт тоже должен так делать.
Решил пока не выкладывать (ну нахуй местную аудиторию), но по крайней мере успел до нг высраться на итч рабочим онлайн билдом.
>Где ваши игры?
Прототипируются, тестируются, рефакторятся. Несколько разочаровался в гексах, но в целом для 4х грант стратегии самое то. Картинок красивых нет, потому что один код. Поэтому на тебе жориков (плейсхолдер)
Гедонизм, это примитивные управляющие стимулы, а созидание, это высшее проявление живой природы по противодействию вселенской энтропии.
Двачую
С наступающим всех
Мы с тяночькой как раз вместе допиливаем игру, она художник, я код пишу. Это наш путь, ламповый.
Жизнь меня научила - не делать проекты с родными, друзьями и со своими (временно) тянками.
По-моему все одинокие карлики мечтают найти настолько родственную душу чтобы вместе делать игры, не понятно что у тебя за опыт, вероятно что дело в твоём характере
>она художник, я код пишу
Тяночку зовут Квен, она художник и код пишет, а ты специалист по маркетингу на дваче...
>радиальную консольную
А при чём тут консольные игры? С круглыми меню удобнее всего взаимодействовать с помощью обычной компьютерной мышки, а не с помощью джойстика. Джойстики неудобны независимо от типа интерфейса, и я видел много консольных игр с обычным сеточным инвентарём. И наоборот, многие компьютерные игры добавляют круглые меню.
>слишком много в радиальное меню не впихнёшь
Вообще-то, круглым меню можно пользоваться даже со 180+ кнопками... Хотя мой код сейчас делает очень много лишних вычислений и тормозит, но я планирую, что в моей игре не будет ситуации, когда игроку нужно сразу 180 кнопок в меню. Ситуация здесь как со вкладками в браузере - ты можешь открыть хоть 1000 вкладок, но ты сам будешь в этом виноват.
В большинстве игр, что я играл, предметов в инвентаре много потому, что:
1. Стопки предметов ограничены, но игроку нужно много одного предмета.
2. "Уникальные" предметы, реальные отличия между которыми несущественные.
В своей игре я не буду делать ограниченные стопки - даже если у тебя миллионы копий одного предмета, все они умещаются в один сектор меню инвентаря, и мне хотелось бы избежать создания почти неотличимых, но "уникальных" предметов. Ограничение инвентаря будет только по суммарному весу предметов в инвентаре, который должен будет влиять на поведение дирижабля: игра позволяет тебе сложить миллион камней в одну стопку в одном сундуке, но тогда твой дирижабль перекосит на сторону этого сундука и им будет сложнее управлять. Поэтому игроку будет нужно распределять ресурсы более равномерным образом (и ещё потому, что сундуки изнашиваются).
Также преимущество круглых меню в том, что площадь интерактивной области на экране зависит от числа кнопок в меню. В типичном сеточном инвентаре, если отдельная кнопка малюсенькая, то ты вынужден прицеливаться с помощью мышки в эту малюсенькую кнопку даже если она у тебя единственная на всём экране - это сильно раздражает. А искать что-то нужное среди сотен кнопок в любом случае неудобно, так что какой-то пользы от сетки всё равно нет. В общем и целом, сеточный инвентарь замедляет взаимодействие с игрой по сравнению с более быстрым круглым меню, и это даже с учётом того, что круглое меню можно красиво анимировать, а сеточный инвентарь слишком "жёсткий" для анимаций.
Радиалки это гавно из прошлого показавшие свою неэффективность, помню одно время их пихали повсюду в игры и софт, в итоге оставили в консольных играх в виде комманд, которые зафиксированы статично, если их немного то на стиках удобно использовать, а так радиалки это больше когнитивной нагрузки для человека, особенно когда элементов много и они динамичные, людям удобнее списки/таблицы с фильтрами или категориями.
Одно из преимуществ инди-хобби-разработки - ты можешь делать как хочешь, а не как надо.
Но согласен, тяжело воспринимается (возможно просто с непривычки, хз).
Меня вот в рпг выбешивают инвентари с разным размером ячеек, где приходится в подобие тетриса играть, пик (хз для иммерсивности это или для затягивание геймплея, или я не понимаю).
>А при чём тут консольные игры?
Хз, просто оно у меня ассоциируется со всякими ГТАшечками
>Вообще-то, круглым меню можно пользоваться даже со 180+ кнопками...
Как в этом месиве найти Предметнейм, особенно если не помнишь его точное название или иконку? Да даже если знаешь примерное положение, пойди попади мышкой в нужный пиксель. А на стиках вообще ад будет.
Олсо, полезно посмотреть видос Марка, чтобы не топтаться по чужим граблям: https://www.youtube.com/watch?v=e4vsgC41bYg
(заголовок обманывает, про юнити там чисто условно, видео про дизайн UXа)
Другой анон. Раньше всегда все делали инвентарь или списком или просто полем, на которое в любое место можно положить любой предмет. Сейчас какая то деградация случилась с этими ячейками тетриса ебучего. Типо не только вес, но и размер учитывается. Но как по мне духота ради духоты. Хуже только поломка снаряжения
Финальный спиральный вариант выглядит еще хуже.
Таблица по вкладкам вроде как самая вменяемая, но проблема настанет если элементы не статичны - добавишь ежика и твой гномик уже сместился и придется переключать позиционную (почти мышечную) память на поиск гномика (и большие таблицы людям даются сложно). Они не зря используют во втором варианте ограниченную таблицу с предпросмотром.
Скорее всего разработчики лукавят и весь замысел что ты будешь использовать только последние часто используемые, а не летать по всему списку.
Самое удачное что я видел (для большого числа элементов) это мод skyUI. Это список, иконки и группы по тексту. Кажется это тоже мудрено, но в реале это удобно (родное меню там вообще бездарный ад).
Это хорошо смотрится во всяких ждалкерах/тарковых. Но не в игре, где мультяшная жопастая тян путешествует по летающим островам, да.
>>1067125
Никто не говорил, что спиральный вариант идеальный, но он точно выпендрёжный и прикольный; опять же, в BG&E он вполне хорошо работает. Суть была в том, чтобы посмотреть разные варианты и оценить их плюсы-минусы, потратив 20 минут на просмотр видео, а не несколько дней на реализацию.
Олсо, для больших инвентарей, ящетаю, всегда нужно делать текстовое поле поиска, причём желательно неточного.
>радиалки это больше когнитивной нагрузки для человека
Но, по-моему, чем меньше элементов - тем легче мозгам.
>>1067122
>Как в этом месиве найти Предметнейм
Точно так же, как и обычно, но двигать мышкой намного проще - вбок и по кругу.
>пойди попади мышкой в нужный пиксель
В круглом меню можно расширить чувствительную зону сектора до бесконечности. Я это не реализовал, но уже знаю, как это можно сделать - просто пока что потребности в этом не было. Если вкратце, курсор нужно скрыть и накапливать сдвиг мыши - чем дальше от центра сдвигаешь мышь, тем проще будет выбирать пункт меню - одним резким взмахом мышки в сторону повышаешь точность.
>>1067125
Вот на твоих скриншотах хорошо видна проблема большинства игр с инвентарями: там всего 2-3 по-настоящему уникальных предмета, а всё остальное - это повторы этих предметов с бесполезными модификациями. Вот, например, один предмет делает громкий "пыщ" и наносит урон, а другой предмет делает то же самое, но вместо 99 урона наносит 100 урона - и ради этого нужно было делать две строчки меню вместо одной? Или вот другой предмет позволяет избежать урона от врагов, а другой предмет делает то же самое, но компенсирует не 99 урона, а 100 урона - и ради этого они стоят на разных строчках? Такие предметы-обманки делают специально чтобы создать лишнюю "когнитивную нагрузку", типа, "вот у нас тут тысяча предметов, поди разберись, какие из них лучше", а на деле всё сводится к тупому закликиванию врагов любой палкой в любой броне. Да и даже если ты делаешь в игре тысячу таких предметов, которые отличаются на +1 к урону или +1 к защите, игрок в любом случае будет использовать только один такой предмет, а все остальные либо обменяет на стакающееся золото, либо переплавит в стакающиеся слитки - и то, и другое можно отобразить всего одним пунктом меню вместо огромных списков. Хотя некоторые игры идут ещё дальше и делают два десятка разных видов слитков металла, отличающихся друг от друга настолько незначительным оттенком спрайта, что их легко перепутать...
Ну и потом, есть большая разница между играми, где инвентарь - это единственное место хранения (РПГ), и играми, где у игрока может быть тысяча отдельных сундуков (Minecraft), между которыми приходится физически бегать ножками, чтобы что-то где-то найти.
>>1067126
>посмотреть разные варианты и оценить их плюсы-минусы, потратив 20 минут на просмотр видео
Это как говорить "лучше посмотреть летсплей, чем играть в саму игру, если нужно поучиться аспектам геймплея какого-то жанра"...
>жопастая
Это ты ещё не видел новую версию...
>Меня вот в рпг выбешивают инвентари с разным размером ячеек, где приходится в подобие тетриса играть, пик (хз для иммерсивности это или для затягивание геймплея, или я не понимаю).
Для затягивания и добавляет слой сложности, взять тебе пару зелий или кафтан на продажу. Конкретно эти, с пика, зашкварные мудилы, которые постоянно усложняют игру как только игроки находят способ в неё играть. ну и с рождения игры там всё для магов делалось, не знаю есть ли сейчас, раньше спавнилась хижина ведьмы около города, с полным сетом на мага - шляпа посох роба и что то ещё
Круглые меню - самое то для "паркура".
>Точно так же, как и обычно, но двигать мышкой
А ты не из тех, кто может быстро выхватить глазами из кучи иконок нужную, да? Обязательно по одной перебирать?
>расширить чувствительную зону сектора
Не оч понятно. У тебя по одной угловой секунде на сектор. Ты предлагаешь, чтобы попасть в нужный, размахнуться мышкой по всему столу? Как узнать, в какой именно надо целиться, если они все съёжились до полосочек? Как ты "расширишь чувствительную зону" при управлении со стика?
>Это как говорить
А для таких душнил там ещё и демка на итче. Мне лично и так понятно, какие тут основные проблемы.
Нихуя ты гениален! Аж по доброму завидно. Релиза тебе и сундук с золотом в Новом Году!
Воспоминание разблокировано. Спираль из BGE, йеее!
>>1067125
> Финальный спиральный вариант выглядит еще хуже.
Потому что это дурачок-инфоцыган так криво реализовал. В оригинальном BGE (которое показано в видосе) всё реализовано красиво и удобно. И я напоминаю, первый BGE это классическая игра, когда диды умели делать игры.
>зашкварные мудилы, которые постоянно усложняют игру к
У них в начале (может и сейчас тоже) была проблема - отсутствие контента.
Поломка оружия / пустые промежуточные локации. Проходя данж вынужден вернутся через 3-4 пустые локации к кузнецу чтобы починиться. А там еще писоть-какоть-спать тоже зовут домой.
И вот у тебя уже псевдо занятость и даже не заметно что на карте всего 3 данжа.
Еще маленький инвентарь, наполовину забитый хилками и едой, он тоже может заставить идти продаться или закупиться (теми же хилками и едой).
Казалось бы - у тебя 2D вы там все художники (судя по качественной рисовке) - сделай интересный мир для игрока, отвяжи ты его от таверны, пускай погуляет. Нет проще сделать перки с неявной синергией и продать стримерам как соуслайк (в пошаговом мире, лол).
Дропнул бы игру с таким инвентарём как только его увидел бы.
Жуткая отталкивающая хуйня, говорящая о том, что автор шизик, не понимающий как и зачем вообще в игры играют, и ничего хорошего и интересного от игры ожидать не стоит.
>У них в начале (может и сейчас тоже) была проблема - отсутствие контента.
Контента добавили давно и города и перки и галимых персонажей (своего вроде до сих пор не сделать) но...
>Поломка оружия / пустые промежуточные локации. Проходя данж вынужден вернутся через 3-4 пустые локации к кузнецу чтобы починиться. А там еще писоть-какоть-спать тоже зовут домой.
>Еще маленький инвентарь, наполовину забитый хилками и едой, он тоже может заставить идти продаться или закупиться (теми же хилками и едой).
Это осталось (навсегда). Спать можно в лагерях бандитов но это давно было сделано.
Ну если ты совсем давно не заходил, то там даже шкуру добыть надо очки скилов тратить на скил охотника или типа того, отдельно скил на разведение костра и т.п.
В данже убрали проходы в 1 клетку и все теперь минимум 2 клетки чтоб ты не сделал паровоз из врагов. Количество врагов в комнатах увеличили, если раньше 1-2, редко 3 (на боссе) то теперь (точней в 2024 когда я был последний раз) их по 4 в комнате, редко 3. Авторы считают что ты должен набирать ловушки, расставлять их, заводить пачки на них, короче страдать и пердолиться
>>1067146
Забавно, конечно, как безыгорные чмони рассказывают как нужно и ненужно делать игры, приводя пикрелейтед в пример как ненужно и очень плохо.
Сразу понимаешь, что мнение безыгорных чмоней ОЧЕНЬ важно и к ним действительно надо прислушаться... и делать наоборот.
Ну мы обсуждаем проблему множества предметов. К скайриму и так много вопросов. В реале у тебя не так много мусора (там меню сундука/торговца), если ты не отыгрываешь роль данж-пылесоса. Беседка специально завозит множество предметов, в надежде что потом модеделы нахаляву сделают моды (например еда в игре не нужна, но ее тонна там, явно расчет на писоть-какоть-выживач)
Но вот проблемы с множеством сундуков - это вот реальная проблема.
В скайриме я не испытывал сложность, из-за бесконечных сундуков мне требовалось 3-4 места хранения. В реальности с таким меню хватило бы и одного, но "места производств" в разных местах (а ты чаще берешь все под перегрузку).
В других рпг разгрузиться после похода целая головная боль, даже видел в игре "авторазгрузку" когда подходишь к сундукам, жмешь кнопку и стаки сами складываются (если они есть). Но что-то найти там - это адище (как и заниматься сортировкой).
И вот парадокс, по идеи бесконечный сундук портит иммерсивность. Но нет. Скайрим настолько насыщен контентом, что такой подход кажется даже оптимизацией рутины.
Тот же момент с лошадью. Есть мод который в лошадь добавляет инвентарь. Но некоторые города (и почтив все данжи) отделены от игрового мира где эта лошадь стоит и приходиться бегать по частям - чтобы продаться или оптово закупиться. Так вот, есть отдельны мод позволяющий получить доступ к лошади удаленно. Казалось бы опять порча иммерсивности ("глина") - но нет, по началу по приколу бегать до лошадки, но потом это утомляет, у тебя и без этого есть контент (в идеале бы сделать какую-то волшебную сумку-портал и купить потом за большие деньги и все - иммерсивненько).
В общем, надо просто играть в свои игры, именно поэтому мододелы иногда (не часто) делают решения лучше разработчиков (если нет цели искусственно удлинить рутину).
Я вот страдал фигней в скайрим и опытным путем вычислил что самый комфортный вес для игры оказался 800-1000 (а не 300). Больше уже глина, меньше не позволяет пылесосить без делеммы что выкинуть. Куда столько золота - я сделал перки за деньги. да я знаю что в игре 100500 способов разбоготеть, я тестил именно лут с данжей
Или вот с едой, если голод теребит тебя раз в 12 минут - это адище (это не юзер мод, а платные моды беседки, без баланса). Но вот если раз в час, то не напрягает и в тоже время смысл еды не теряется тоже. То есть, можно добавить нормальный выживач в рпг не испортив игру.
Ты перепутал, ты не в /vg. Здесь как раз люди разбирают кухню и закулисье геймдева. Сделать игру на разводах не очень то и сложно (затягивай геймлей, делай типа соуслайк данжи и купи стримеров - и вся школота твоя и пофиг что игра некомфортная, прибежит такой как ты и будет дефать чужую игру за бесплатно).
Мы как раз обсуждаем как должен выглядеть нормальный геймплей для игрока.
Вспомни отзывы в начале публикации, что с тех пор изменилось? Ничего, кроме того что у авторов появились деньги на маркетинг. Раз в год выходит обнова где двигают цифры туда-сюда и добавляет одного персонажа в пустую игру. Ну явно тут не проблема в нехватке идей (которые явно тащат с bb). А помнишь как люди бомбили, когда лютню завезли в синг игру (опять же в пустую игру)? Для чего? А чтобы стример побаловался, для видео-контента. Понимаешь теперь для кого делается игра?
PS
Они же вроде аналогичную игру про космос завезли? У людей явно есть свободно время, но чет контент не завозиться. Вот и думай.
>что автор шизик, не понимающий как и зачем вообще в игры играют, и ничего хорошего и интересного от игры ожидать не стоит.
Ты сейчас описал весь инди (и около инди) геймдев. Местами некоторые решения это буквально васянские моды. Но у шизика могут быть такие креативные идеи, что потом они станут новой нишей индустрии.
Кстати, нередко разработчики вообще мало играют в игры.
>Контента добавили давно
Пытаюсь фоном просмотреть, чтобы увидеть что добавили. Так как играть и разбираться в "синергии" перков желания нет .
Вижу, что данжи стали детальнее и красивее, вроде. По визуалу к ним претензий нет. Даже жаль что они решили пошаговый стиль выбрать, а не что-то более динамичное (думаю, скачущий юнит оттолкнул многих).
Зачем-то прикрутили лагерь если есть повозки между городами.
С повозками можно было прикрутить свой особняк/дом. Скорее всего опять с bb утащили. Только там стратегическая карта это основной геймплей и юнит есть "лагерь" сам по себе (с мнимой повозкой и прочим).
>Это осталось (навсегда). Спать можно в лагерях бандитов но это давно было сделано.
Всегда нравилась идея что ГГ может спать в данжах или лагерях бандитов, где в соседней комнате враги, или в округе дикий мир (и может еще бандиты).
На земле спать не может, а в обоссанном матрасе, который воняет от недавнего потного мужика с клопами - самое то.
>Ну если ты совсем давно не заходил, то там даже шкуру добыть надо очки скилов тратить на скил охотника или типа того, отдельно скил на разведение костра и т.п.
То есть, не добавили контент, а удлинили за счет старых возможностей и предметов (я помню шкуры на весь инвентарь были, ведь шкуры не свернуть, шкура это кольчуга, как и накидка в 6 слотов. Зато есть пустые тарелки, реалистичность)
>В данже убрали проходы в 1 клетку и все теперь минимум 2 клетки чтоб ты не сделал паровоз из врагов.
Лол, это прям был основной геймплей от прохода. Сейчас я вижу стримеры стоят около выхода и в случае чего выходят из данжа, потом заходят снова и так несколько раз. Соуслайк который мы заслужили.
>Авторы считают что ты должен набирать ловушки, расставлять их, заводить пачки на них, короче страдать и пердолиться
Авторы хотят чтобы стример страдал - завозил контент, а зритель шел покупать, ведь столько эмоций в игре. Но в реале стримеры находят новый абуз и все выглядит опять стремно.
>Города
Это контент, но от открытого мира хочется немного другого.
Показываю дауну настоящие метрики
1) Пролог прошли только треть игроков
2) Хотя бы одно задание выполнила только половина игроков
3) Как и прошли туториал игры
т.е. половина игроков даже не играла
Так в чем проблема? Попробуй для начала портануть скайрим на годот. Отличная задача лет на 10-20 для хоббиста. У тебя даже OpenMW для примера есть откуда можно спиздить реализацию папируса и прочее геймбрио специфичное.
>Сделать игру на разводах не очень то и сложно
И ты бы даже сделал и заработал свои десятки миллионов баксов, но ПРОСТО НЕ ХОЧЕШЬ.
Понимаю.
>RenderingServer забивает на него
Да, должен забивать, см. тут:
https://docs.godotengine.org/en/stable/classes/class_performance.html
>Monitor RENDER_TOTAL_PRIMITIVES_IN_FRAME
>The total number of vertices or indices rendered in the last rendered frame. This metric doesn't include primitives from culled objects (either via hiding nodes, frustum culling or occlusion culling). Due to the depth prepass and shadow passes, the number of primitives is always higher than the actual number of vertices in the scene (typically double or triple the original vertex count). Lower is better.
>скрываю обьекты - кол-во трисов не меняется
Возможные причины:
1. Они уже скрыты одним из способов:
- frustrum culling (поворот камеры);
- visibility range (дальность от камеры);
- occlusion culling (перекрытие объектами);
- автоматический level of detail (для GLTF);
- их предок в дереве уже был скрыт.
2. Ты где-то ошибся и объект ещё виден.
3. Какая-то ошибка в коде профайлера.
>Как правильно ныкать обьекты?
Если ненадолго - то hide() или visible = false.
Если надолго - то remove_child():
>var hidden_object: Node
>func show_object(): add_child(hidden_object)
>func hide_object(): remove_child(hidden_object)
Если очень надолго, тогда вообще queue_free():
>var hidden_object_scene: PackedScene
>var hidden_object: Node
>func show_object():
>_ hidden_object = hidden_object_scene.instantiate()
>_ add_child(hidden_object)
>func hide_object(): hidden_object.queue_free()
Смотри по ситуации, что тебе нужно.
>Так в чем проблема?
Я в геймдеве относительно недавно.
1) Первая проблема нехватка знаний по движку и в целом по геймдеву. Я пока в такой стадии, где метаюсь от тестовых проектов к тестовым, повторяя или ковыряя что-то определенное. Нужно какую-то массу набрать, чтобы чувствовать себя уверенно (я бы еще по математике немного прошелся бы).
2) 3D, там отдельный пласт знаний и опыта моделинга, текстуры и анимация.
2D мне сейчас позволяет погрузиться в саму разработку делая быстро затычки. А если я начну делать "двигающиеся кубы" я немного просяду и придется отвлечься от движка и учить блендер, набивать руку.
3) Да, 3Д дает хорошее погружение, но какой объем работ.
Тут в своих перделках (стратегиях) есть шанс закончить, а скайрим-подобное нереалистично. Но, конечно, можно полгодика попробовать поковырять какую-нибудь мини бродилку.
Обидно только то, что ты будешь делать что-то месяц, а игрок пробежит за 5 минут. Неблагодарная штука, для индюшника.
4) Лоу-поли крайне специфичная тема, сразу "80% фу!", а без сарафанного радио тяжело.
Мне думается, что флеш-стиль 2Д менее ущербнее смотрится чем лоу-поли.
>портануть скайрим на годот.
Не хочу сам скайрим. Я скорее про то, что давало бы такое же погружение, мир-песочника, но в тоже время был вектор развития. Есть в таких играх такой "огонек", который заставляет человека полностью погрузиться, то есть создать иллюзию мира в котором, условно хотелось бы жить.
Я бы хотел попробовать передать этот момент, через открытый мир, взаимодействие с миром и противостояния сторон (например классно, быть эльфом и проникнуть во вражеский город ночью, скажем орков, ограбить и слинять. При этом в городах эльфов подымать репутацию и быть своим).
Вот 2д сеттинге, это еще выглядит достижимым, главное не сделать гибрид Stardew Valley со стоуншардом.
Так одно дело сделать такую игру и другое сделать такую игру популярной. Тебе же конкурировать с такими же.
Они не релизнули еще игру, стали делать клон, понимая что сливки возможно собраны.
Они за год делают то, что ты за месяц можешь (кроме лютни).
Геншин тоже не стали в глубину развивать проект, а стали клон пилить.
Обрати внимание на стартовые квесты геншина, у них явно была задумка данжей, но потом поняли что люди хорошо едят и так (бесконечные пустые диалоги, которые нельзя скипнуть).
Если ты в играх не видишь искусственное затягивание геймплея то, что ты в геймдеве забыл? Вернись в /v
Это была ирония, чел. Хочешь игры делать соло - сперва учись делать контент. Программирование и движки для тебя вторичны.
>Хочешь игры делать соло - сперва учись делать контент
Гуманитарное мышление. Сделать более качественные модельки поверх готового геймплея куда проще. Причем геймплей может меняться в процессе разработки. Где-то даже кто-то видео кидал, как ААА игру делали сначала на плейсхолдерах квадратах. Более того готовый временный ассет с определенной анимацией может задавать ложный геймплей. В итоге ты будешь делать какую-нибудь боевку под анимацию плейсхолдера, это ошибка с точки зрения дизайна.
>Программирование и движки для тебя вторичны.
Вчера спросил у Квина тик менеджер. Если гпт5 и дипсик почти не тупили, то это чудо предложило сделать на таймерах годота. Так вот если ты программист - ты еще увидишь плохую сгенерированную картинку, но если ты художник, как ты поймешь что код плохой? Слишком много очень тонких моментов, которые надо понимать. Как тот момент с дергающейся линией, или что _ready работает по восхождению и что нужно инстанс определять внизу дерева, а не вверху как в обычном программирование.
Ты одуреешь плавающие ошибки ловить, если не контролируешь что в коде происходит и как под капотом работает движок.
Код и движок первичен.
>Это была ирония, чел.
Не зря, я пока писал проанализировал для себя почему это мне не нужно. Одно дело мимолетное воодушевление, другое дело взвесить все здраво.
>Гуманитарное мышление
Я на физика учился в свое время и 10 лет коммерческий код пишу.
Интересность геймплея от кода не зависит. От того что ты BFS и AStar изучишь и сам реализацию напишешь. - игра не станет интереснее, чем в случае если бы ты скопипастил скрипт из чатжпт.
Если научишься делать контент: сочинять истории, делать модели, рисовать, анимировать - ты можешь и без кода обойтись делая игру. Потом уже можешь и кодинг изучить если понадобится. Если сначала начнешь копаться в движках, еще сам начнешь движки писать, потом обнаружишь что до хорошей игры, в которую будут играть другие, тебе все также как до луны.
>Я на физика учился в свое время и 10 лет коммерческий код пишу.
Как это отменяет гуманитарное мышление? Знал бы ты сколько гуманитариев сейчас джейсоны перекладывает. Если 30-40 лет назад программист представлял из себя реально инженера или математика, то сейчас это ни о чем не говорит.
> ты можешь и без кода обойтись делая игру
Ты не видел как человек часами методом тыка перебирает в коде какую-то шляпу, вместо того чтобы пойти прочитать все API которое он вызывает и понять почему здесь так происходит. Ты по опыту должен знать что это слишком сложная система, чтобы работать с ней по принципу "авось".
>>1067199
>Если научишься делать контент: сочинять истории, делать модели, рисовать, анимировать - ты можешь и без кода обойтись делая игру. Потом уже можешь и кодинг изучить если понадобится.
Возможно ты хотел сказать что надо делать красивые игры? Ну это и так понятно. Но зачем игнорировать программирование? Я же говорю гуманитарное мышление.
Я имел ввиду что надо хотя бы уметь адаптировать готорый контент под твою игру. Eще сложнее один и тот же стить тиражировать на целую игру. Ты же не хрючево для свиней из чего попало готовишь, а игру для людей.
Игра это часть искусства, какое бы оно попсовое не было, тебе нужно вырабатывать вкус. Если программирование решается изучением в течении нескольких месяцев, то искусство требует дроча навыка годами. Если ты не сможешь это делать сам, тебе придется платить кому-то за постоянную работу хужожником.
Проблема кода уже решена движком, практически. То что там кто-то не может цикл написать, это вообще относится не к трудности изучения программирования, а к тому что данному челу общего IQ не хватает.
>Я имел ввиду что надо хотя бы уметь адаптировать готорый контент под твою игру. Eще сложнее один и тот же стить тиражировать на целую игру. Ты же не хрючево для свиней из чего попало готовишь, а игру для людей.
Делой хорошо, плохо не делой
Я это понял, но как это отменяет факт что проще сначала базу сделать и потом плейсхолдеры заменить? Причем визуал ты можешь надрачивать до бесконечности.
>Игра это часть искусства
Но это не говорит что код вторичен.
Я увидел что гексы херова смотрятся на длинных путях для реалтайм движения/боя. Представь у меня в моменте поменялся целый концепт игры, а что было если бы сначала ассеты делал? Я бы стал адаптировать проблему под игру, просто потому что я уже потратил силы на графику. Да, поменял анимацию для пошаговой стратегии, но что если я не хочу пошаговую? Или бы заставил местность, чтобы косяки скрыть. То есть, я бы стал тупо замазывать косяки.
Это как если машину сначала покрасить, а потом начать её рихтовать. Ведь рихтовка вторична.
>>1067208
>Проблема кода уже решена движком, практически.
Ну если у тебя игра уровня новеллы.
В реале движки вообще мало чего дают. Даже контроллер персонажа/камеры у каждого чуть ли не свой.
В целом твое критическое мышление можно свести к одному:
Если мне легко программировать, значит всем легко программировать, посоветую пойти сначала рисовать, ведь мне рисовать сложнее
Физик, 10 лет в галлере, итоги.
>Делой хорошо, плохо не делой
Да. Только для того чтобы в программировании делать достаточно хорошо нужно условно несколько месяцев покодить на выбранномм двигле. Для того чтобы визуально делать хорошо нужно годами дрочить визуализацию и анимацию и пр. Даже ассетфлипом нужно уметь заниматься, потому что игре нужен единый стиль. А стиль вырабатывается оче долго.
Я же не говорю не надо изучать годот. Но игродел это визуальное искусство. База там, а не в годоте или юните и пр.
Пока ее не освоишь, будет результат как в ТВГ
И твой пример про переключение на другой тип игр не корректен. Даже небольшие студии пилят одно и то же годами. Как те же ларианы. Все по той же причине.
>Я же не говорю не надо изучать годот.
Ты буквально сказал вторично.
Ну, в общем, мы пришли к выводу. Кодинг и API учатся быстро, а искусство бесконечно.
Выберите что учить первым сами.
"Искусство никогда не бывает законченным, только брошенным." - Леонардо да Винчи
Хочу высказать наблюдения (структурировать мысли) и быть может натолкнуть кого-то тоже на свою мысль.
Есть идея 2D РПГ в стиле Stoneshard (да, там есть первоисточник жанра, но я не помню название). Кто не знает. У нас постоянно пошаговый мир, на одно движение игрока (на один тайл/взаимодействие) происходит движение игрового мира (также на тайл/взаимодействие).
(+) Что это дает нам в плане плюсов.
- Неторопливый геймплей, при этом если нужно, можешь передвигаться также быстро, почти как реалтайм (остановить мир? - просто остановись сам). Можно ограничиться управлением мышкой (играть даже лежа).
-Сама "пошаговость" хорошо ложится в облегченное 2D, можно опять же придерживаться минимум анимации, достаточно дать просто визуала для взаимодействий (не рисовать взмах оружия в руках, а просто провести анимацию разреза, лязг, перекраска врага в белый цвет).
Что даст больше времени на работу с общим визуалом или геймплеем.
-Если есть элемент гринда, с мышкой он чувствуется проще, чем wasd. Скажем, нужно рубить, просто кликаешь на дерево (через меню UI или кнопку или взяв в руки инструмент-топор). Нужно рубить много - прокликал через шифт или выделением мышки (ого, этот чел не хочет затягивать геймплей!! фу!).
(-) Что это дает нам в плане минусов.
- Одинаковая скорость передвижения всех юнитов. Раненный в ногу или волк движется с такой же скоростью как и ты.
Да, можно компенсировать скилом с кд, когда юнит иногда может сходить 2-3 клетки, имитируя быструю скорость, или игнорировать ход из-за травмы (последнее очень раздражает если дебаф на игроке). Но все это больше костыли.
- Нет возможности произвести тяжелые вычисления, если хочется динамичный очень сложный мир (очень). Да, игрок может долго думать перед действием, но также может просто быстро перемещаться, почти реалтайм, тогда он почувствует пропуки. Как вариант делать реально "тяжелое" между загрузкой локаций или во время сна (эта проблема такая же как и для реалтайма, поэтому притянута за уши, можно просто не мудрить. Навеяно идеей как в 4х стратегиях можно повесить все вычисления между ходами).
-Пошаговые боёвки очень однообразны (во всех играх, во всех вариациях), это буквально повторение одного и того же паттерна боя. Очень скучно. А мы знаем - основной геймплей не должен быть нудным.
Будут мысли, накидайте защеку.
Вчера по-быстрому накидал систему уведомлений о входящих в инвентарь предметах. Не хотелось сбавлять темп работы, но теперь, думаю, мне нужно вернуться к дизайн-документу и спланировать следующие шаги. Пытался сделать диздок к этой игре уже несколько раз, и каждый раз забрасывал его, так что теперь многие старые записи неактуальны, несмотря на то, что общий вектор развития не поменялся. Почему-то мне сложно придумывать конкретные детали.
Далее - ответ всем сразу: я делаю эту игру для себя, и поэтому добавляю то, что мне самому нравится или не вызывает у меня отторжения или неудобства. Круглые меню мне эстетически приятны и мне с ними проще взаимодействовать - у меня всегда были проблемы с мелкой моторикой, так что двинуть мышкой в каком-то направлении мне проще, чем прицеливаться в мелкие кнопки (если они не выглядят так, будто сделаны для сенсорного экрана).
Если кому-то не нравятся круглые меню и тому подобное - что же, вы не попадаете в мою целевую аудиторию, и ничего плохого в этом нет. Я осознаю, что моя целевая аудитория крайне узкая, если вообще существует, но я не стремлюсь сделать какую-то всемирно известную "игру для всех". Даже подумываю о том, что будет безопаснее забиться в загон к "18+" и не высовываться оттуда, чтобы случайные дети не кликнули на цветасто-мультяшную картинку и не травмировали психику.
Концептуально я больше всего вдохновляюсь опытом "штормовых стен" из Worlds Adrift. Представьте: летите на дырявом деревянном корыте с 4 дымящими двигателями из каких-то гнилых палок, влетаете в шторм - всё трясётся, трещит, один из двигателей внезапно отрывается и сносит вас с палубы, так что вы едва не теряете своё корыто из виду, начинаете лихорадочно бегать и пытаться "вбить" ресурсы в оставшиеся у вас движки, но пол под ногами тоже ломается и всё закручивается - уже непонятно, куда вы движетесь, но лишь бы не оставаться на одном месте, иначе от корыта ничего не останется... Вырываетесь из шторма, падаете без сил на оставшийся кусок палубы, двигателей осталось лишь два, а ресурсов хватит на починку лишь одного... Ощущение, будто игра тебя изнасиловала, но при этом чувствуешь кайф от прилива адреналина и идущего за ним расслабления.
Но у Worlds Adrift была масса проблем. Перечислять долго, но, например: сбор ресурсов был унылым из-за неотзывчивого управления, слишком жёсткой верёвки, огромных расстояний на островах для движения пешком, необходимости искать и сортировать много видов ресурсов, между которыми было мало разницы; создание каркаса корабля было приближено к унылой работе в программе для 3D моделирования, что позволяло делать кучу лишнего, мешающего в реальной игре, а установка почти всех запчастей ограничена фиксированной на острове "строительной верфью"; игра никак не стимулирует движение вперёд и не предоставляет никакой мобильной опасности кроме других игроков, которые могли на порядки превосходить одиночку. Что разработчики сделали в Lost Skies? Повторили все те же самые ошибки и проблемы, только теперь монстры сильнее бьют, но их позиции фиксированы, поэтому игра сводится к: "ты мог бы пойти куда угодно, но тебе никуда не надо". С другими похожими играми (летающие острова, корабли) та же проблема: "строй что хочешь и лети куда хочешь, но это скучно и тебе это не нужно". Другие же игры чересчур серьёзно относятся к "выживанию"...
В общем, я хочу сделать игру-госпожу, что бьёт игрока хлыстом, подгоняя и наказывая, но делает это нежно. Меня не устраивает, что под "хардкором" подразумевают "одна случайная ошибка и начинай всё с нуля". Я хочу, чтобы игра адаптировалась под игрока и поддерживала его в состоянии напряжённого бегства, но прощала ошибки. Т.е. ты испытываешь адреналин от прохождения шторма с потерей до 100% накопленных ранее ресурсов, но чувствуешь, что это было справедливо, и получаешь удовольствие от восполнения ресурсов в моменты относительного спокойствия.
Где в этом "круглое меню инвентаря"? Нигде. В прошлом я не думал, что буду делать инвентарь, планируя ограничиться простой надписью типа "дерева столько, газа столько" как это бывает в RTS играх. Но в то же время инвентарь мог бы пригодиться, и мне не хочется захламлять экран лишними индикаторами, так почему бы не сделать это меню привлекательным визуально?
>>1067141
Спасибо, но я просто пытаюсь повторить то, что меня чем-то привлекло в чужих играх...
>>1067155
Есть игры, где нужно заранее планировать действия по определённой системе - это "игры-меню", т.к. ты выбираешь путь среди заранее известных "кнопок" в "подменю" возможных событий. Есть игры, где ты действуешь по ситуации, в текущем моменте, не планируя заранее - это "игры-паркур", т.к. ты "прыгаешь" от одной ситуации к другой как по разным постройкам в городе, без чёткого плана. При этом и те, и другие игры могут относиться к "экшенам"; но, я думаю, даже пошаговые игры могут являться "игрой-паркуром", если вся игра - это лишь реагирование на предыдущий ход противника или текущее состояние игрового поля.
Вот я склоняюсь к созданию "игры-паркура"... наверное, во всех смыслах. Нужно будет обязательно реализовать зацепление за край острова/платформы, и, вероятно, "бег по наклонной поверхности". Ещё думаю о том, какие прикольные анимации можно реализовать в воздухе (не копируя из других похожих игр)... Честно скажу - никогда не занимался паркуром в реальной жизни и даже не интересовался им, так что реализм в этом плане меня не волнует - я хочу сделать именно мультяшные движения. Не уверен только, насколько хорошо это будет сочетаться с геймплеем - почти все анимации должны будут быть резкими, чтобы не препятствовать управлению персонажем и не нарушать ритм игры. Давно об этом думаю, но 3D моделька слишком сырая...
>>1067197
>Хочешь игры делать соло - сперва учись делать контент.
Согласен. Навыки создания интересного контента в соло важнее создания сложных систем, поскольку на практике многие популярные игры технически просты, а игровые движки уже имеют множество готовых решений на все популярные жанры. Успешных игровых механик не так много, как интересного контента на различные темы - мало кому интересно играть с условными квадратиками или кубами, даже если механика выбрана правильно и реализована хорошо. В то же время в игре на интересную тему, богатую на контент, игроки готовы терпеть неуместные, кривые и багнутые механики...
Вот меня привлёк Worlds Adrift чисто своим контентом (летающие корабли из всякого мусора, летающие острова), и я терпел его механики только чтобы открыть побольше контента (запчастей, островов), и был больше всего разочарован в том, что контента в игре практически не было; я бы и дальше терпел механики, баги и лаги, если бы там было больше доступного контента. В своих проектах я долго придерживался подхода "сделать геймплей на серых кубах", но я почувствовал интерес и фан от своих механик только когда добавил к ним чуть более детальные модельки с хотя бы примитивными, но работающими анимациями. Сейчас одна из моих проблем с моей игрой именно в том, что я не могу придумать разнообразный контент - у меня есть базовый геймплей, но я с трудом представляю, что делать в плане контента.
>>1067198
Геймплей и анимации сильно взаимосвязаны - трудно сделать хорошую боёвку от третьего лица, пока твой персонаж - неподвижная серая капсула. Нужны хотя бы ключевые позы на лоуполи модельке с правильными пропорциями - длина рук, ног и т.д. Так что, если хочешь делать 3D игру, постарайся научиться работать в Blender как можно раньше. Создание игры - это как написание картины: от широких мазков и общих очертаний фигур ко всё более мелким деталям - мелкие детали не появляются сами собой на чистом холсте, под ними всегда грубый "эскиз", в контексте игр - "прототип". В видеозаписях прототипов ААА игр как раз видно, что у них были грубые прототипы персонажей с грубыми анимациями даже на самых ранних этапах разработки, когда весь остальной игровой мир представляет собой набор серых плоскостей, поскольку персонаж - центральная фигура, на которую наращивается остальное, и с персонажем-капсулой у них не получилось бы сдвинуться с места. Разумеется, модель-прототип должна соответствовать игре, а не быть случайным готовым ассетом, взятым из интернета.
>Tales of Maj'Eyal?
Там вроде ascii-графика была, но вроде оно.
Стоит добавить в минусы босс файты. Унылее, наверное, труднее придумать. А ведь нельзя сделать лучше, тебе неизбежно надо оставлять какое-то "окно" чтобы игрок наносил урон и не получал урон (в итоге 30 минут повторения одних и тех же действий).
Тем временем Quasimorph выглядит интереснее. Есть, конечно, сомнительные решения, но такой "XCOM в космосе" выглядит неплохо.
Вот так и должны делаться игры. Для себя. Без оглядки на кого-либо. Делаешь игру в которую интересно играть самому - и тогда аудитория появится.
Моя любимая еда - вобла с молоком. Если я открою ресторан, аудитория появится?
Если вместо стульев будут унитазы, то может на найдутся любители подристать.
Ты про который в assetlib лежит? Лучше play gama сдк используй сразу. Он намного удобней. В том яндексном сдк ещё и ошибки в html и js файлах, там что-то не работает корректно с лидербордами, придётся самому переписывать. Я долго сидел на этом сдк, заебался постоянно править его и перешёл на play gama.
К тому же с сдк play gama больше площадок юзаются.
У меня обьявлены классы, скажем
class_name Slot
class_name SlotEquip extends Slot
class name SlotHead extends SlotEquip
Как мне сделать строгую проверку на SlotEquip? Через is я получу true и в случае с Slot, через get_class() я получаю вообще встроенный класс. is_class() тоже. Чё делать, я не пойму?
>Через is я получу true и в случае с Slot,
Нет.
is SlotEquip гарантирует, что у объекта есть те же поля, что у класса SlotEquip, т.е. это или SlotEquip или его потомки
Нет, просто IoC/DI не работает. Либо прибивать гвоздями иерархию сабсцен, ограничивая идею динамического графа. Либо выкинуть IoC/DI (что я и сделал).
Ну типа сама архитектура кривая. Ты обязан делать так чтобы дети не знали о родителях, а потом в качестве решения суют NodePath с хардовой иерархией всех родителей по всему коду.
Ну не придурки? идея что ты каждый раз из родителя будешь пробрасывать в потомков зависимость (В КАЖДОМ УЗЛЕ) - вообще бред
@export хоть как-то облегчает эту боль.
Система кривая, ценности проброски IoC нет, просто хардкорьте пацаны.
>>1067641
Кстати читали бест практис?
https://docs.godotengine.org/en/stable/tutorials/best_practices/scene_organization.html
Костыль на костыле, чтобы система сабсцен работала.
В любом фреймворке с DI есть простой доступ к зависимостям через контейнер. По сути любой DI содержит сервис локатор для твоего случая. Но это не значит что надо везде отказываться от инжекции через конструктор. В scene graph - через локатор. В самих зависимостях - через конструктор. Ноды дерева сцены вообще через композицию, а не DI
>Ну типа сама архитектура кривая.
Да
>Ты обязан делать так чтобы дети не знали о родителях
Да
>а потом в качестве решения суют NodePath с хардовой иерархией всех родителей по всему коду.
Да, или через синглтон G/Global/GameObject/GodObject
>идея что ты каждый раз из родителя будешь пробрасывать в потомков зависимость (В КАЖДОМ УЗЛЕ) - вообще бред
Да, поэтому существуют группы и уникальные имена(%), ими можно закрывать такие вопросики и даже отказаться от синглтонов(заменив на какой-нибудь коренной скрипт в дереве, например)
> отказаться от синглтонов(заменив на синглтоны
Блять, синглтонофобы начинают заёбывать. Юзайте шину сигналов инкапсулированную в глобальный сигнал. Нода знает о существовании глобального сигнала и может его излучить. Другая нода знает о существовании такой штуки как глобальный сигнал и может на него подписаться. Всё. Архитектура чистейшая. Никто никого не знает. Кроме глобального сигнала, который кое что знает, но никому не скажет.
>сервис локатор
get_node() - это он и есть (ты же инстанс ноды получаешь, причем со своим скриптом, как будто инстанс своего класса). Собственно от него и хочется избавиться, он привязывает нас к глобальному состоянию.
кстати, на него работает автокомплит в редакоре от твоего скрипта, так что организовывать код в виде нод имеет какой-то смысл
Понятно что свои местные (локальные к сцене) скрипты тебе хочется через конструктор проинжектить, это хотя бы покажет их организацию.
Но вот инжектить сапсцены смысла нет. Чем сложнее проект (количество сапсцен), тем противнее будет инжектить на каждом узле.
Синглетон не нужен, единственно что полезное показали в бестпрактис это то, что можно сделать главную ноду над всем, даже над уровнями(игровыми сценами).
Шинодебила не слушай.
>Синглтоношиз был, шиношиз был, ioc шиз нарисовался, интересно, кого еще нелегкая принесет
Наверное даже слегка обидно, что у тебя своего мнения какого-то нет. Нормис в треде, правлю NodePath ручками каждый день и не парюсь
>Да, поэтому существуют группы и уникальные имена(%), ими можно закрывать такие вопросики и даже отказаться от синглтонов
Толку от уникальных имен, если у тебя нет точки где ты можешь их засетапить. То есть, тебе нужен глобальный скрипт или main нода. А если она уже есть, нафига тебе уникальные имена, у тебя еще один сервис-локатор/контейнер есть.
Пикча решает 99,9% проблем инициализации гундоти.
Теперь ты можешь _ready использовать как конструктор.
>Блять, синглтонофобы начинают заёбывать
Пройди нахуй тогда
>>1067652
>Шинодебила не слушай.
И не планировал
>>1067654
>Патчедебила не слушайте.
Можно послушать группыдебила
>>1067655
>Толку от уникальных имен
ты всякой заумной ненужной хуйни про
>сервис-локатор/контейнер есть
начитался, а базовые простые вещи не освоил, что _ready родителя выполняется после _ready детей и пытаешься писать, будто это не так, решая проблему которую сам и создал
>начитался, а базовые простые вещи не освоил, что _ready родителя выполняется после _ready детей и пытаешься писать, будто это не так, решая проблему которую сам и создал
О чем ты, я дергал сервис локаторы, когда они еще не были антипаттерном.
Я кстати, это слово уже лет 15 не слышал, ну контейнер и контейнер. Пустил старую пхп слезу.
Чтоб не поесть говна при следующем рефакторинге, в годоте нужен небольшой контейнер поверх NodePath, это очевидно даже без сапсцен.
Я отказался от проброски IoC и идеи модульности, а так локатор хоть и костыль, но он удобен.
> сапсцен
Суп. Супсцен. Так правильно. Супсцены и борщсцены.
> Нода знает о существовании глобального сигнала и может его излучить. Другая нода знает о существовании такой штуки как глобальный сигнал и может на него подписаться. Всё. Архитектура чистейшая
Ты же создал синглтон для этого, ведь правда?
Ладно, вот мне нужен функционал TileMapLayer в моем сторонней борщсцене, как мне его получить? Сигналом?
> мне нужен функционал TileMapLayer
Создай инстанс TileMapLayer.
> в моем сторонней борщсцене
Да где угодно.
>>1067671
Нет ты.
Если нужно передать кому-то сложный инстанс обьектного типа, то лучше юзать DI в этом я солидарен с DI-дебилом.
шинодебил
Шины не нужны
Ioc не нужны
Синглтоны не нужны
Di не нужен
Сервис локаторы не нужны
Группы не нужны
Стейтмашины!
>>1067689
Делай всё на стейтмашинах!
https://youtu.be/d1l26se0Ruk
Не хватает знаете кого? Человека который все состояние игры хранил бы в одном дереве ассоциативного массиве (dictionary) и который бы топил, что нужно писать на лиспоподобном языке.
Чтобы потерять уютный пост дебила с сервис локатором?
Нее.
Решил для начала запилить вариацаю на тему Space Invadres, но в 3D и в фентези.
Вчера разбирался с интерфейсом годота, читал документацию и запилил зеленый пол и туретку-игрока, способную двигаться вправо-влево в ограниченном диапазоне.
Сегодня запилил возможность этой туретке стрелять проджектайлом, заранее сделал переменные скорости проджектайла и скорострельности, с прицелом на возможные будущие паверапы, увеличивающие эти характеристики.
Параллельно замоделил и развернул модельку игрока - паровую туретку, которая будет ездить вправо-влево по рельсам.
Плюсы:
- Редактор инстанцирует твой скрипт за тебя.
Если нужно засетапить перед использованием - сетапишь в родителе (в сцене) в _ready() отдельно, типа "$Child.setup(a, b, c)".
- Есть автокомплит редактора в нотации через "$" (но нет в get_node()). Пик2
- Можно опускать class_name (это может быть важно для мелких скриптов, чтобы не засорять глобальный список имен и оставить его только для реальных сервисов/менеджеров).
- Понятно что все пользуются Ctrl + P, но так же такой подход показывает все скрипты для сцены, не нужно ориентироваться в файловой системе (особенно если скрипты глубоко в папке сцены).
- В теории, такие кодовые-ноды будут инстанцироваться чуть быстрее чем создание из gds.
Минусы:
-Не решает проблем архитектуры и NodePath, просто другой подход.
-Засоряет сцену. Нужно держать в сабноде, чтобы хотя бы свернуть весь код.
-При переименование ноды - придется переименовывать скрипт ручками (а как ты хотел?).
-Я организовывал так, что все скрипты которые имеют _proccess() лежать на сцене, а все вспомогательное просто в папке. Тут так уже не выйдет, все на сцене.
-Для нормального автокомплита придется все равно заводить имена class_name или как деды - по памяти.
>заранее сделал переменные скорости проджектайла и скорострельности, с прицелом на возможные будущие паверапы
Заранее думать о будущем, залог успеха.
Осталось определить к какой ты группе относишься:
Синглтон-макака
Шино-шиз
Контейнерный-дебил
НодПас-нормис.
Это очень важно для дальнейшего диалога.
Не очень понимаю, о чем речь, но думаю что к клону space invaders это все неприменимо, ввиду экстримальной простоты концепта.
Я вообще 3дшник и просто хочу сделать интерактивную играбельную витрину для 10-15 лоуполных (до 500 трисов) ассетов с хп текстурками.
>Я вообще 3дшник
Главное в очко не долбиться.
>>1067736
У бабки анимация как-будто из 3д портировали кадры. Сам делал?
>Вы забыли про того гения что пытается игру нейронкой сделать, включая 3д ассеты
Его поглотила ИИ-сингулярность и он давно уже в 25 измерении.
> Не очень понимаю, о чем речь, но думаю что к клону space invaders это все неприменимо, ввиду экстримальной простоты концепта.
Карочи, у нас тут синглтоно-боярин.
https://www.youtube.com/watch?v=x7L3BqCC4Do
Тепеь я мог добавить ноду AnimationPlayer, создать там анимацию shoot в которой менял размер и угол ствола и в скрипте проигрывать эту анимацию при каждом выстреле. Потом я в том же AnimationPlayer создал новую анимацию дрожащих труб, назначил ей зацикленность и автоматическое проигрывание со старта. Но при этом когда я нажимал выстрел и соответсвенно активировал строчку кода animation_player.play("shoot") у меня останавливалась моя анимация выхлопных труб.
Решил проблему добавлением еще одной ноды AnimationPlayer02, в которой сделал анимацию труб.
В общем в итоге все работвает как я хотел, но меня не покидает ощущение что я дико накостылил. Как можно было все это сделать по другому?
Чел
https://www.youtube.com/@FelesMachina/videos
всё по сосаликам включая шаблон проекта
надо было из glb в окне импорта во вкладке Mesh достать отдельно меши
> Как можно было все это сделать по другому?
>повставлял их как MeshInstance3D
Технически ничего не изменилось. Ноду модельки можно развернуть через контекстное меню и там будут лежать те же мешинстансы. Пихать модельки в сцену перетаскиванием GLB западло, ящитаю. Делай .tres. Лично я говноед и неригганое экспортирую в fbx, пушто меня бесит как glb колбасит меш по развертке
>Решил проблему добавлением еще одной ноды AnimationPlayer02, в которой сделал анимацию труб.
Есть такая темка, называется Animation Tree. Можешь поиграться.
>Одинаковая скорость передвижения всех
Поиграй в нормальные rogue-like игры (рогалики), там этот вопрос давно решён. Ты думаешь концепцией "хода", но на практике один твой "ход" (предпринятое действие) делится на множество "тиков", количество которых зависит от разных параметров. Если в обычном состоянии перемещение на 1 клетку занимает 10 тиков, то в ускоренном состоянии займёт 5 тиков, а в замедленном - 20 тиков. Если у другого персонажа скорость перемещения 15 тиков, то это означает, что в нормальном состоянии на каждые 3 твоих клетки этот персонаж пройдёт только 2 клетки; когда ты замедлен, то на каждые твои 3 клетки этот персонаж пройдёт 4 клетки. Это подразделение "ходов" на "тики" также решает проблему скорости атак, включая каст заклинаний и прерывание: если ты маг и кастуешь мощное заклинание, оно занимает у тебя 30 тиков, но если рядом стоит разбойник и атакует тебя, а каждая его атака занимает 5 тиков, тогда ты либо не сможешь прочитать заклинание, либо получишь 6 ударов ножом разбойника в процессе чтения заклинания. Если ему ещё добежать до тебя надо, то будет зависеть от скорости его движения и расстояния.
>Нет возможности произвести тяжелые вычисления
Эта проблема никак не связана с пошаговостью и решается просто: эти твои "тяжёлые вычисления" либо разделяются на группы и выполняются по одной группе за один тик, либо выполняются в фоновом процессе. Простой пример: ты хочешь, чтобы деревья постепенно росли, но их у тебя 1000 штук на сцене, и делать 1000 операций "роста" каждый кадр слишком затратно. Сколько у тебя стадий роста дерева? Скажем, стадии роста три. Сколько времени (ходов) должно пройти до перехода дерева в следующую стадию роста? Скажем, 3600 тиков (1 минута при 60 кадрах в секунду). Если ты будешь растить только одно дерево каждый тик, тогда, разумеется, часть деревьев дойдёт до последней стадии на 1000 тиков позже, но это не так важно - ведь в реальной жизни деревья не растут синхронно. Более того, чтобы сделать эту симуляцию более естественной, будет лучше выбирать дерево случайным образом, чтобы не было видимого паттерна обновления деревьев. Аналогично с любыми другими растениями, животными, автоматическими постройками и т.д.
>Пошаговые боёвки очень однообразны
>>1067507
>босс файты. Унылее, наверное, труднее придумать.
У вас просто хороших пошаговых игр (рогаликов) не было, вот и жалуетесь... Пошаговость игры тут вообще никаким боком, всё зависит от геймдизайна боёвки. Игра в реальном времени тоже будет однообразной, если всё, что может делать игрок - это, например, "целиться и стрелять", при том что многие 3D РПГ игры даже не дают целиться, а вся боёвка состоит из "закликивания насмерть"...
>У вас просто хороших пошаговых игр (рогаликов) не было
Я единственно что придумал, это убрать предсказуемость паттерна "ударов" (зарандомить) и всю нагрузку переложить на броню/увороты и расходки.
Проблема только в том что я не малолетний деб ребенок и даже не знаю понравится ли такое им (что надо больше готовиться к файту, а сам файт рандомище). Ведь они привыкли выучить паттерн босса и долбится в него 30 минут.
>зарандомить
>рандомище
Босс должен "сигналить" следующий удар, помечая клетки, на которые он приземлится, выстрелит, нанесёт удар и т.д. Также должно быть возможно увидеть доступную врагу зону движения, видения и атаки посредством выделения его клетки (также, как и в случае игрока, только контролировать нельзя). Это база, как о таком можно не знать?
>малолетний ребенок
Я думаю, в пошаговые игры играют люди от 20-30 как минимум, а то и старше. Дети до 20 предпочитают экшн-игры, где время реакции решает всё, потому что у детей как правило (но не всегда) с этим проще - шутеры всякие, МОБА и т.п. Как вообще завлечь ребёнка тем, что выглядит и играется подобно шахматам, где у тебя одна пешка против толпы?
>выучить паттерн босса и долбится в него 30 минут
В какой пошаговой игре босс может отнимать 30 минут? Максимум минут 5 - и то, это если долго готовиться... Это в экшн-играх делают босса типа "губка для патронов", в которую ты стреляешь 30 минут, изредка перекатываясь, потому что ничего лучше стрельбы (закликивания) и перекатов геймдизайнеры не придумали, а занять игрока чем-то нужно.
>Не делайте так
Я вообще не понял - зачем ты это пытался сделать? Заняться нечем?
>>1067640
>Ты обязан делать так чтобы дети не знали о родителях
Да, это естественный ход вещей в Godot.
>а потом в качестве решения суют NodePath с хардовой иерархией всех родителей
Какого решения? Кто суёт? Зачем? Никто не заставляет использовать NodePath, тем более никто не заставляет трогать root-ноду, тем более - идти от неё к каким-то другим нодам в дереве. Ты сам себе в ногу выстрелил зачем-то. Зачем?
>идея что ты каждый раз из родителя будешь пробрасывать в потомков зависимость (В КАЖДОМ УЗЛЕ) - вообще бред
Почему "в каждом узле"? Только там, где тебе реально нужно что-то. Если нужно очень много где - ты где-то ошибся.
>>1067649
>Юзайте шину сигналов... Никто никого не знает...
Удаляю файл с "шиной" из проекта, где 1000 файлов дёргают её по глобальному имени: +1000 errors. Твои действия?
>>1067655
>99,9% проблем инициализации
Инициализация в Godot очень простая и понятная.
1. Вызывается _init объекта. Если есть обработчик с аргументами - он обрабатывает их.
2. Если это десериализация, то устанавливаются значения переменных в @export.
3. Если это нода и она добавляется в дерево - то происходит _enter_tree.
4. Если у ноды есть потомки - у них вызываются _init, _enter_tree и _ready.
5. После всех потомков вызывается _ready, т.е. "вся сцена загружена и готова".
Какие выводы можно сделать из всего этого?
- каждая нода способна работать по отдельности, без каких-либо конкретных предков;
- потомки ноды-предка важны для её корректной работы, поэтому они включаются первыми;
- нода-предок включается последней и сразу может оперировать всеми своими потомками;
- если нужно обязательно поменять порядок, тогда нода-предок должна делать так:
>func _ready() -> void:
>_ add_child(CHILD_SCENE.instatiate())
Тогда _init, _enter_tree и _ready внутри потомка сработают строго после _ready его предка.
>>1067660
>вот мне нужен функционал TileMapLayer в моем сторонней борщсцене, как мне его получить?
Добавляешь эту стороннюю сцену как потомка TileMapLayer и передаёшь ей ссылку на себя:
>func _ready() -> void:
>_ var player := PLAYER_SCENE.instatiate() as Player
>_ player.map = self
>_ add_child(player)
Проблема решена.
Если у тебя несколько TileMapLayer, то, очевидно, у тебя есть некий GameWorld, который делает:
>@onready var _navigation_layer := $NavigationLayer as TileMapLayer
>func _ready() -> void:
>_ var player := PLAYER_SCENE.instatiate() as Player
>_ player.map = _navigation_layer
>_ add_child(player)
И всё. Как видишь, ничего сложного в этом нет (напечатал прямо здесь, в форме поста двача).
>>1067674
>Сигналы нужны для обмена примитивными типами данных.
>Если нужно передать кому-то сложный инстанс обьектного типа, то лучше юзать DI
Бред какой-то, объекты в этом плане ничем не отличаются от "примитивных типов". Пример:
>func _on_button_pressed(sender: Button) -> void:
При чём с какой-то версии Godot этого "sender" можно добавить одной галкой в GUI редактора.
>Босс должен "сигналить"
Ничего не должен. Пришел к боссу - страдай.
Босс не проститутка чтобы его вызывать по кд и бить с подсказками.
Подсказки казуал для слабеньких.
>Я думаю, в пошаговые игры играют люди от 20-30 как минимум,
Соулсятину, точнее босс-файты играют те кому нужно самоутвердиться на игре. Это проблема юношеского максимализма, взрослые уже не хотят видеть в играх "вызов", она хотят развлечение или погружение (конечно есть и там и там исключения, мы же разные).
Тут недавно было два человека, один защищал стоуншард, а другой плевался. Два человека два разных взгляда и скорее всего возраста.
>В какой пошаговой игре босс может отнимать 30 минут?
Это я смотрел стоуншард.
>Я вообще не понял - зачем ты это пытался сделать? Заняться нечем?
Это вопрос архитектуры и получить модульность и в тоже время простоту, чтобы бойлерплейт не писать. Годот дает слишком большую свободу, NodePath сладкая булочка, которая испортит игру.
>>1067760
> Ты сам себе в ногу выстрелил зачем-то. Зачем?
Там рабочий вариант, скорее вопрос перфекционизма, когда много сабсцен.
Хотелось рыбку съесть, и в пруд не лезть.
>>1067760
>Инициализация в Godot очень простая и понятная.
Конструктор лучше не дергать, даже в промышленной разработке избегают (ну как минимум в спринге), а тут еще нет точки входа.
_ready тоже лучше не дергать.
Единственный вариант это инжектить (IoC/DI) в какой-то кастомный метод (пик).
Еще держать рядом локатор, на случай если сабсцена будет иметь зависимость, чтобы руками не пробрасывать по всем сабсценами (на случай очень большого проекта)
>>1067760
>- каждая нода способна работать по отдельности, без каких-либо конкретных предков;
Ну мы понимаем что если они добавят start, то вся идея сабсцен пойдет по ветру. В тоже время восходящие и нисходящее поведение база везде, кроме годота.
>1. Вызывается _init объекта
А, перед _init ещё происходит присвоение данных полям, типа такого:
>var number: int = 5
Это произойдёт до _init, но только если нет метки "@onready" перед ним.
@export десериализируется точно после _init и точно перед _ready/@onready.
Если у вас setter на @export и в нём доступ к @onready свойствам, тогда придётся так делать:
>@export var data: Data = "data":
>_ set(v):
>_ _ data = v
>_ _ if not is_node_ready(): await ready
>_ _ somenode.data = data
>@onready somenode := $Node as Node
Тогда кусок кода, обращающийся к somenode, выполнится после $Node, иначе будет обращение к null.
>>1067730
>недооценённая фигня, это организация кода в виде нод прям на сцене
Тыщу раз обсуждали уже, но это имеет смысл только когда тебе РЕАЛЬНО ТРЕБУЕТСЯ разделить твой код на несколько отдельный файлов-скриптов. Если тебе это прямо сейчас не нужно - одумайся и не дроби код лишний раз. Ты, конечно, можешь буквально для каждой переменной и каждой однострочной функции создавать отдельный .gd файл и потом делать гигантскую портянку Node в дереве, но зачем? От скуки? Лишнее дробление кода ухудшает его читабельность. Ты всё равно не будешь динамически отключать-подключать эти ноды, а если ты в них что-то поменяешь - наверняка что-то сломаешь и потом будешь долго искать причину поломки по всему проекту, т.к. ты засунул эти ноды непонятно куда.
>для мелких скриптов, чтобы не засорять глобальный список имен
Что значит "засорять глобальный список"? У тебя в любом случае будут длинные имена классов, забей на "засорение"...
>оставить его только для реальных сервисов/менеджеров
Которые в любом случае будут называться типа: WhateverService, WhateverManager и т.д. В чём проблема-то, лол?
Просто не называй свои классы одной буквой. Двумя буквами тоже не называй. Тремя тоже не стоит.
Но если ты реально не хочешь "засорять", тогда можно делать так:
>const Weapon = preload("res://weapon.gd")
Это позволяет создавать экземпляры "безымянного" класса по имени:
>var weapon := Weapon.new()
Это имя будет доступно только в рамках класса, где оно объявлено. Но если этот класс откуда-то доступен (по ссылке или по глобальному имени), то получившие доступ тоже могут создавать экземпляры этого класса по заданному в нём имени:
>var weapon := Instruments.Weapon.new()
Так можно организовывать классы во что-то вроде "namespace", храня их в отдельных .gd-файлах. Вроде бы у этого подхода есть некие ограничения, но если ты боишься "засорить" поле имён, то этот скрипт наверняка малозначим для твоего кода.
>инстанцироваться чуть быстрее
Это буквально экономия на спичках и преждевременная оптимизация. У тебя ещё игры нет, а ты уже о каких-то мелких, вспомогательных, буквально безымянных скриптах волнуешься - зачем? Ты удивишься, но упереться в скорость GDScript возможно только если у тебя там какой-то математический код в нескольких вложенных for за один кадр крутится. Лучше позаботься о том, что у тебя игры нет и оптимизировать пока нечего, а вот потом уже будешь оптимизировать...
>Не решает проблем архитектуры и NodePath
Какие проблемы ты пытаешься решить?
>Нужно держать в сабноде, чтобы хотя бы свернуть весь код.
Сколько сотен таких "скриптовых нод" ты собираешься напихать в одну сцену, лол?
>При переименование ноды - придется переименовывать скрипт
Делаешь "@export var my_script_node: MyScriptNode" и выбираешь ноду в инспекторе.
>все скрипты которые имеют _proccess()
Ты вообще не должен создавать обработчик _process в 99.99% своих скриптов - только там, где тебе РЕАЛЬНО НУЖНО обрабатывать буквально каждый ВИЗУАЛЬНЫЙ кадр игры. Если ты не следуешь этому принципу, то игра будет сильно тормозить независимо от каких-либо оптимизаций, особенно если у кого-то игровой дисплей на 120/240 Гц.
Обычно твой код дожидается сигнала, вызова метода, сеттера или геттера; в крайнем случае юзай _physics_process. По сравнению с _process, у _physics_process фиксированная частота, которую движок старается удерживать без изменений. Задаётся эта частота в настройках проекта и может сильно отличаться от частоты кадров независимо от монитора, но она будет полностью синхронизирована с событиями физического движка, что важно для практически любого геймплея. Для сглаживания движений можно включить интерполяцию физики - она сгладит любые трансформации из твоего кода.
Кстати, _input тоже не стоит использовать лишний раз - это самый глобальный обработчик, который хватает вообще все события ввода, даже те, которые предназначены твоему GUI - поэтому по умолчанию лучше использовать _unhandled_input.
Я играю в соулсятину ради эксплорининга и кайфа от открытия секреток и шорткатов. Какой то особенный челлендж сосаликов это миф.
>Ничего не должен. Пришел к боссу - страдай.
Тогда игрок не должен тебе позитивный отзыв. Сделал "сложную" игру - страдай.
>Босс не проститутка чтобы его вызывать по кд и бить с подсказками.
Игрок не проститутка чтобы его вызывать по кд и бить нечестными противниками.
>>1067763
>босс-файты играют те кому нужно самоутвердиться на игре
Офисному работнику, который хочет набить морду ИРЛ боссу, но боится потерять работу?
Старой домохозяйке, которая хочет набить морду ИРЛ мужу, но боится потерять зубы?
Боссу, который хочет набить морды ИРЛ этим двоим, но боится потерять репутацию?
>не хотят видеть в играх "вызов", она хотят развлечение
Поэтому "босс" должен заранее предупреждать о своих ударах и выставлять напоказ подсвеченное уязвимое место.
>Тыщу раз обсуждали уже
Я в годоне чуть больше месяца.
>Лишнее дробление кода ухудшает его читабельность.
Ну SOLID надо знать.
Мне понравился подход код-нода. Какая-то гармония, что у тебя все сущности сцены перед лицом, свернуть не долго ноду (да и переделать тоже).
>а если ты в них что-то поменяешь - наверняка что-то сломаешь и потом будешь долго искать причину поломки по всему проекту, т.к. ты засунул эти ноды непонятно куда.
Ого, а тут другая буковка, которая решает эту проблему SOLID
>Которые в любом случае будут называться типа: WhateverService, WhateverManager
В игре теряется смысл Service, Manager писать эту чепуху не стоит, какое-то подражание бэкенду (там это нужно, тут нет).
Как базу написать, так портянки городите, как по делу молчите.
Спасибо за советы, буду учиться программированию :)
>Я играю в соулсятину ради
Человек может завуалировать потребности до бесконечности.
Не видел интересный мир в сосалках.
В любом случае мы говорим про ~60% (по Гауссу). Что делают остальные 40% только Кодзиме известно (и его сыну, который в движкосраче сидит)
>Тогда игрок не должен тебе позитивный отзыв. Сделал "сложную" игру - страдай.
Срать, я художник я так вижу. Понятно что надо балансить, но задрачивание паттернов это лоускил. Ты и собаку надрессируешь.
У тебя на скриншоте какой-то бредовый хаос. Что и зачем ты делаешь?
>xx.game
Почему ты назвал это "xx"? Тебе настолько лень пичатать букфы, что ты ниасилил напичатать "xxx"? А почему не "sex"?
>tick.setup()
Если этот код - в _ready предка, тогда твой "tick" уже готов. Вопрос в том, что он делает? И зачем? В Godot уже есть тики.
>util.setup(tick)
Что за это за "утилиты", которым нужен "тик"? Утилиты - это чистые функции (статические методы), а не какие-то объекты.
>$UI/ButtonSpeed.setup(tick)
Это вообще смешно. Если ты хочешь менять скорость тиков, то должен делать это через обработчик _on_button_pressed.
>$Camera2D.setup(tick)
А это тебе зачем? Дай угадаю - ты там выводишь количество тиков в label на экране? Или что? Явно какой-то твой косяк.
>_world.setup("FirstWorld")
В Godot такие вещи делаются вот так: add_child(load("res://worlds/first_world.tscn").instantiate()), запомни это.
>tml = _world.getCurrentWorld()
Зачем ты залез в его кишки и ковыряешься? Тебе не стыдно лезть в приватные части посторонних объектов?
>tile.setup(tml)
Ты в курсе, что "tile" - это одна-единственная очень маленькая клеточка? И зачем ты ей суёшь этот... что это?
>player.setup(tile, tick)
Лол. Ты мог бы удалить весь этот код, если бы следовал идеологии Godot, а не изобретал свой велосипед...
>Конструктор лучше не дергать, даже в промышленной...
Где ты таких дурацких вещей набираешься? Это новый челлендж в тиктоке?
>а тут еще нет точки входа
Это и есть первая точка входа, не считая инициализации полей.
>_ready тоже лучше не дергать
Кто тебе это сказал?
>Ну мы понимаем что если они...
Ты просто не понимаешь инструмент, которым пытаешься пользоваться.
>>1067769
>чуть больше месяца
Вот видишь - все проблемы из-за твоей неопытности, нехватки опыта программирования.
>Ну single responsibility principle надо знать.
Лучше знай You aren't gonna need it и Keep it simple, stupid, а то запутаешься в коде.
>Какая-то гармония, что у тебя все сущности сцены перед лицом
Они у тебя так и так "перед лицом", если ты правильно организуешь свои сцены.
>буковка, которая решает эту проблему
Нет у тебя никакого интерфейса - ты напрямую перебрасываешь объекты их пользователям.
>писать эту чепуху не стоит
Тогда у тебя не будет разницы между, скажем, Enemy и EnemyManager (если он тебе нужен).
>как по делу молчите
По какому делу-то, у тебя ничего кроме каких-то примитивных шестиугольников ничего не было...
>Игрок не проститутка чтобы его вызывать по кд и бить нечестными противниками.
Никто не говорил про отсутствие баланса.
>Офисному работнику, который хочет набить морду ИРЛ боссу, но боится потерять работу?
Возможно, я уже писал выше про распределение по Гаусса. Человек может играть в игру даже просто потому что понравилась анимация героя, но таких будет не 60%.
>Поэтому "босс" должен заранее предупреждать о своих ударах и выставлять напоказ подсвеченное уязвимое место.
Ничего не должен, игра должна давать баланс и тактику (особенно в пошаговой).
>тактику
Нет никакой тактики в том, чтобы набраться лечилок и танковать мордой совершенно случайные, непредсказуемые атаки, о которых узнаёшь только за счёт уменьшения своего здоровья. Тактика в игре - это когда ты уже знаешь, куда противник собирается ударить, и можешь, на выбор: увернуться, отразить, закрыть собой союзника, закрыться телом союзника, подставить ловушку, пнуть другого противника под этот удар, использовать взаимодействие стихий удара и чего-то ещё и т.п. Если ты не знаешь, куда ударит противник, то всё это многообразие становится невозможным - ты либо танкуешь урон, либо умираешь.
>баланс
Балансировать нужно фановую игру. Если фана в игре нет, то балансировать её бесполезно. От того, что твой игрок будет вынужден повторить нудное неинтересное действие 5 раз вместо 50 раз, это действие не станет увлекательным для него.
В любой нормальной игре боссы демонстрируют начало атаки до того, как по игроку проходит урон - это база. Ты обычно можешь легко заметить, как босс пятится назад перед прыжком, как светится дуло перед мощным выстрелом, как босс рычит перед особо мощной атакой и т.д. Иногда такое поведение есть и у более слабых монстров, но чаще всего именно у боссов. Потому что иначе игрок будет проигрывать не из-за своей ошибки, а из-за того, что ему просто не повезло с рандомом - а это нечестно и бесит.
>особенно в пошаговой
Да, особенно в пошаговой. Потому что в пошаговой ты не можешь увернуться от медленно летящего снаряда, если он, конечно, не будет лететь со скоростью пешехода. В играх в реальном времени у тебя есть хотя бы пара сотен миллисекунд, чтобы физически уклониться.
>Почему ты назвал это "xx"? Тебе настолько лень пичатать букфы, что ты ниасилил напичатать "xxx"? А почему не "sex"?
Гормоны? Использование сервис локатора должен быстро находиться в коде. Это тоже самое как делают принты через xxx() или маркеры //@@@@// чтобы потом быстро снести отладочный код (или найти).
Набрав xx. - я найду все места где забыл сервис локатор.
>Если этот код - в _ready предка, тогда твой "tick" уже готов. Вопрос в том, что он делает? И зачем?
это TickManagerUltraService - так привычнее??
> В Godot уже есть тики.
Да? Где? Гугл меня обманул опять?
>Что за это за "утилиты", которым нужен "тик"? Утилиты - это чистые функции (статические методы), а не какие-то объекты.
Генеральный класс "Util" это место где собираются методы, которые еще не созрели чтобы стать отдельными сущностями предметной области, а так же хелперы.
Видишь как удобно, в утил классе есть какая-то замануха, которая зависит от тик менеджера. Надо выносить куда-то - это очевидно, но мы не будем создавать класс ради одного метода (да?)
>>$Camera2D.setup(tick)
>А это тебе зачем? Дай угадаю - ты там выводишь количество тиков в label на экране? Или что? Явно какой-то твой косяк.
Интересно да? Магия какая-то, сам не понимаю как работает, но работает (видео)
>Это вообще смешно. Если ты хочешь менять скорость тиков, то должен делать это через обработчик _on_button_pressed.
Ого, нет я через Win API инпуты ловлю :)
Твой способ нормален, но он не сработает для более сложных анимаций со скелетом.
Читай документацию в первую очередь. По импорту 3D моделей:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_3d_scenes/index.html
По анимации (особенно почитай про AnimationTree):
https://docs.godotengine.org/en/stable/tutorials/animation/index.html
Вкратце, основной метод:
1. Анимируешь свою модель прямо в Blender, т.к. там анимировать намного проще.
2. Сохраняешь анимации как "Action" в NLA, и потом экспортируешь модель как GLTF.
3. В Godot, у твоей сцены уже будет AnimationPlayer, нужно добавить AnimationTree.
4. Настраиваешь порядок и/или смешение анимаций с помощью AnimationTree.
Впрочем, если у тебя примитивная анимация, всё это не обязательно делать...
Также ты можешь анимировать процедурно - напрямую из кода, через Tween:
https://docs.godotengine.org/en/stable/classes/class_tween.html
Это очень удобно, когда точка отправки/завершения анимации неизвестна заранее.
Ты уже и сюда протёк? Вернись в движкосрач, сын Кодзимы.
Или у вас одинаковый стиль письма у всех?
>Ты в курсе, что "tile" - это одна-единственная очень маленькая клеточка?
Очень маленькая клеточка, с весьма высокими целями, между прочим!
>Нет никакой тактики в том, чтобы набраться лечилок и танковать мордой совершенно случайны
-Можно дать статы чтобы убить быстрее
-Можно дать статы чтобы защититься лучше
-Можно то и то, насколько ты времени в игре потерял (как работал так и заработал).
выбирай - шмот, артефакты, редкие игридиенты, готовое в торговле
можешь даже из дума дум пушку притащить (одноразовую), для шанса 0,001% это норм, зато порадует в текущем прохождение.
Так же ты писал - стихии и дыри в уязвимости или защиты.
Ловушки херушки.
Свитки сумонов - нашел, купил, скрафтил - выбирай.
Союзники/наём. Набрал солдат, они его надомажили сколько-то, дальше сам
Наоборот понижающие вещи для босса - туман, яд, кровотечение
Ярость - направить его сумонов против него же.
И это только тут за минуту придумал.
Ну так же само поведение босса.
Ну вот макака в близи больно бьет руками и хвостом, но в дали иногда кидает камни - выгоднее бить издалека.
И наоборот какой-то хер, который видит что ты далеко уходишь - делает жесткое.
Можно добавить отскок (не помню как называют), типа видишь замах, а куда не знаешь - но точно на тебя - на шару прыгаешь. Или свиток тепорта юзаешь или чем-то на мгновение глушишь (тоже расходка дорогая)
>найду все места где забыл сервис локатор
Ну и зачем было его втыкать туда, если потом удалять...
>делают принты через xxx()
Принты делают через print(), иначе забудешь, что это за xxx().
>TickManagerUltraService
Это ни о чём не говорит вообще. Что ты там делаешь такого сложного?
>>В Godot уже есть тики.
>Да? Где? Гугл меня обманул опять?
Да. В Godot. Гугл тебя не обманул - это ты не умеешь им (гуглом) пользоваться.
https://docs.godotengine.org/en/stable/classes/class_engine.html#class-engine-property-physics-ticks-per-second
https://docs.godotengine.org/en/stable/classes/class_engine.html#class-engine-property-time-scale
https://docs.godotengine.org/en/stable/tutorials/scripting/pausing_games.html
На видео >>866799 → можешь полюбоваться на пошаговый рыгалик с полноценной 2D физикой.
>собираются методы, которые еще не созрели чтобы стать отдельными сущностями
Но зачем-то они ведь тебе нужны, не так ли? И где-то используются. Так почему они собрались в каком-то безымянном гадюшнике, где их много и они непонятно чем занимаются, а не в приличном и понятном месте?
>Видишь как удобно, в утил классе есть какая-то замануха
Что удобного в том, что ты не знаешь, куда и зачем что-то передаёшь? Ты сам себя (из будущего) запутаешь. Код должен быть понятным без лишних комментариев и без лишнего заглядывания в детали реализации классов.
В общем случае делаешь так: пишешь где пишется, когда ощущаешь неудобство - выносишь в отдельный класс с нормальным читабельным именем и с чётко обозначенной ответственностью и зависимостями. Заранее выделять классы нужно только если ты чётко понимаешь, что ты делаешь, а не пишешь самый первый прототип игры, о которой ты ничего толком не знаешь, ничего толком не умея делать. Прототип ты всё равно выбросишь, и чем меньше времени ты на него потратишь, тем быстрее сможешь прийти к хорошо разработанной игре.
Алсо, в конкретном твоём случае тебе, скорее всего, нужны синглтоны, а не вот это всё... Т.е. если ты зачем-то решил переизобрести велосипед, который встроен в движок (тики), то и делать это нужно как в движке, поскольку это чисто движковая сущность, которая должна быть глобально доступна по всему проекту (к большому сожалению). Но чтобы делать это безопасно, нужно заранее определиться с её интерфейсом и ни в коем случае его не изменять...
>работает (видео)
Ты не объяснил, зачем Camera2D следить за тиками. Что это ей даёт? Камера либо следит за юнитами, либо управляется игроком независимо от каких-либо тиков юнитов. Камера вообще не существует в игровом мире.
>>1067777
Ты меня с кем-то перепутал, я в Godot-тредах уже несколько лет сижу...
>>1067779
Всё, что ты перечислил - относится к стратегическому планированию, а не к тактике ведения боя. Стратегия - это когда ты заранее готовишься принимать максимум урона лицом и для этого перед боем надеваешь самый толстый шлем, а вот тактика - это когда ты видишь, что босс подошёл к обрыву и ты можешь резким ударом головой сбить его в пропасть - ты не планировал этого делать, но раз уж у тебя всё равно самый толстый шлем, а босс около обрыва, то почему бы и нет? Именно поэтому ты не можешь компенсировать отсутствие тактики через "баланс", если вся твоя игра - это рандомные атаки без предупреждения. В более реалистичных играх (TRPG, JRPG) тактика реализуется через управление целым отрядом (и множество способностей персонажей, направленных на своих союзников, а не только на противников), но мы вроде как обсуждали стандартные западные РПГ/рогалики, где ты управляешь одним-в-поле-воином...
>>1067780
>типа видишь замах
Это и есть тот "сигнал от босса", о котором шла речь. Не обязательно буквально каждую клетку подсвечивать. Хотя даже с подсветкой всех клеток у игрока остаётся риск пропустить возможность вовремя выбраться из зоны поражения.
>Ну и зачем было его втыкать туда, если потом удалять...
П-Р-О-Т-О-Т-И-П-И-Р-О-В-А-Н-И-Е
проброс инъекций утомителен для вещей которые надо быстро попробовать - затычка это нормально
>Принты делают через print(), иначе забудешь, что это за xxx().
Принты могут быть частью нормального апи и ты получишь портянку принтов при поиске. Такую функцию ты не забудешь если часто пользуешься, да и настучать xxx() быстрее чем какой-нибудь console.log(). Плюс там под капотом может быть еще что-то. И это был просто пример, обычно у меня другая функция xxxx() :).
>Да. В Godot. Гугл тебя не обманул - это ты не умеешь им (гуглом) пользоваться.
Сейчас бы не знать что такое тик менеджер в играх. В камеру залетает тик, потому что у меня сложный гибрид, созданный для оптимизации римворд-лайк игры, (с которыми я носился раньше, я просто скопировал сервисы). Залетает значит нужен, не обязательно он там чтобы переопределить _process.
>Что удобного в том, что ты не знаешь, куда и зачем что-то передаёшь? Ты сам себя (из будущего) запутаешь.
У меня большой стаж разработки, я знаю что я делаю (из дерьма конфетку).
Пусть я делаю странное и непривычное, но я делаю правильное. Тут идея была построить гибкую, но в тоже время (важно!) простую систему. Не хочется поверх простых проектов лепить слои абстракций с инжекторами и контейнерами, но в тоже время сам движок ничего не дает чтобы организовать код нормально. Так что все норм, я делаю такую архитектуру, которая останется гибкой даже если проект разрастется (ценой минимального бойлерплейта).
Если тебе кажется что я делаю фигню, это нормально, как и нормально то, что тик менеджер может залететь во все игровые компоненты.
Перестань думать о том что понравится другим и делай то, что понравится тебе. Кроме тебя нет никого.
> Твои действия?
Смеюсь над тобой. Уточняю, что ты ведь и бэкап проекта не сделал? Смеюсь еще громче.
>Алсо, в конкретном твоём случае тебе, скорее всего, нужны синглтоны, а не вот это всё...
У меня же лапки DI, ну фу. Кстати да, ранее тик м. был синглтоном.
>Всё, что ты перечислил - относится к стратегическому планированию, а не к тактике ведения боя.
Вызвать/не вызвать сумона, пить/не пить сейчас банку - это все тактика.
>Ты меня с кем-то перепутал, я в Godot-тредах уже несколько лет сижу...
Что ты, что сын Кодзимы сидите и возводите всякую чепуху в абсолют.
Любое действие в битве будет тактикой (по определению). То что тактика является производным из стратегии, никак вообще ничего не меняет. Сидим дробим шизу на шизу. Все это прекрасно дополняет игру, понятно что в рамках пошагового говна мы сильно ограничены.
> но мы вроде как обсуждали стандартные западные РПГ/рогалики
Это был просто мозговой штурм.
Мне босс-файты вообще не нравятся и у меня их точно не будет.
> где ты управляешь одним-в-поле-воином...
Проблема пошаговой игры - это один и тот же паттерн боя. Отряд, не отряд, все сводиться к одной фигне. Даже в тотал-варе ты очень быстро приходишь к мысли, что игра на стратегической карте интересней чем тактический однообразный бой.
>Перестань думать о том что понравится другим и делай то, что понравится тебе. Кроме тебя нет никого.
Да это понятно, но мотивация (психология) игрока тоже интересна. Я особо даже не геймер.
>time-scale
Кстати, эта же фигня меняет дельту. И если у тебя камера на дельте, а ты скорее всего захочешь на дельте, чтобы при падение фпс не страдала скорость прокрутили и wasd. То тебе придется же корректировать нечто типо delta / Engine.time_scale
Вот тебе и косвенная зависимость от времени
>На видео >>866799 → → можешь полюбоваться на пошаговый рыгалик с полноценной 2D физикой.
Твое? Я так понял каждые несколько лет матрица высирает желающих написать фулл-пошаговую бродилку.
Pong
Arcanoid
Space invaders
Battle City
Kart Racing
Или еще какая легенда с древних консолей/игровых автоматов, но в 3д, с прикрученными паверапами, меняющими ощущение от игры.
> мотивация (психология) игрока тоже интересна
Я играю однообразные гачи в яндексе, чтобы выбить на рулетке год яндекс-плюса. Вот такая мотивация. Ощущаю себя червём.
Ну, вообще, это очень сильный мотиватор.
Люди ради рисованных пикселей готовы долбится часами. А тут выгода в ИРЛ.
Ты просил идею, но не говорил об оригинальности.
Еще можно кастомки из вк3 воспроизводить как стэндэлон игры, с добавлением своих идей.
Вообще мне кажется простые и в итоге успешные концепты возникали когда авторы делали что то просто по фану. Вампайр сурвайвалс, например.
Песни слушать: БОЛЬШИЕ ГОРОДА...
Можно ещё из забаненного роблокса невозбранно пиздить идеи игор. И аудитория прогретая уже есть. Думойте.
Да ну кто хочет игру ради игры, типа игру ради релиза.
Чтобы что? Показать что ты смог, да и так понятно что при должных усилиях любой сможет.
Мне вообще релиз не важен, я могу пилить (поддерживать) проекты вечно. Но мне нужна база для этого, чтобы геймплей не завернулся в тупик через пару часов игры. То есть, глубокая песочница, где концовка больше декорация, чем стимул.
>проброс инъекций утомителен
Именно для этого в Godot есть возможность получить абсолютно любую ноду через $-сахар, который ты не должен оставлять в нормальном проекте. Никаких специальных "локаторов" накручивать не нужно.
>Принты могут быть частью нормального апи
Тогда используй эту функцию:
https://docs.godotengine.org/en/stable/classes/class_@gdscript.html#class-gdscript-method-print-debug
Хотя сам по себе print() это всегда для дебага. Просто обычно он вываливает эти строки в файл журнала, что автоматически удаляется движком в случае, если уже создано 5 журналов (вроде, число можно настроить).
>не забудешь если часто пользуешься
Ты не должен пользоваться print настолько часто. В большинстве случаев код просто работает. Ты явно накручиваешь что-то изначально неправильное, если вынуждаешь себя натыкивать огромное число print().
>Плюс там под капотом может быть еще что-то
Раньше я тоже думал, что мне будут нужны столь сложные выводы в журнал, но потом стал меньше изобретать лишние велосипеды и обнаружил, что в большинстве случаев вывод в журнал бесполезен.
>Залетает значит нужен
Оправдания и ни слова по делу => сам не знаешь.
>У меня большой стаж разработки
Два месяца на Unity и месяц на Godot?
>Тут идея была построить гибкую, но в тоже время (важно!) простую систему. Не хочется поверх простых проектов лепить слои абстракций
Да ты же сам налепил кучу лишнего, из-за того, что пытаешься реализовать "start()" там, где он тебе не требуется, потому что в движке есть "_ready" и т.п. Абсолютно ничего сложного в использовании Godot нет, ты сам себе навыдумывал препятствий.
Если у тебя реально "большой стаж" (хотя бы лет 5), возможно, у тебя уже профдеформация и вызванная возрастом костность мышления: ты выучил какой-то старый инструмент и теперь не способен выучить совершенно новый, которым пользуются по-другому. Успокойся и попробуй читать документацию снова.
>>1067788
>ты ведь и бэкап проекта не сделал?
Наступил момент в проекте, когда вырезать старый костыль и отрефакторить будет рациональнее, чем продолжать опираться на него. Откат назад - это не решение, а бегство от неизбежной работы. Вот ты накопил технический долг и... прячешься от него? Очевидно же, что удаление файла было сделано сознательно, чтобы начать грёбаный рефакторинг. Проект, естественно, взрывается кучей ошибок и отказывается работать в ближайшие недели...
>>1067789
>У меня же DI
А ещё у тебя куча синглтонов в самом движке. Нужно использовать инструменты по необходимости, а не подстраивать всю свою работу под какой-то золотой молоток, который только усложняет работу. В данном конкретном случае (чисто пошаговая игра, где всё существующее завязано на глобальные "тики") этот синглтон оправдан. Обычно я против синглтонов, поскольку они ухудшают читабельность и гибкость проекта, но тут ты расширяешь базовый движок (в принципе, я думаю, лучше сделать модуль движка).
>в рамках пошагового говна мы сильно ограничены
Ты сам создаёшь эти ограничения, лалка. Пошаговые отличаются от реалтайм только наличием автопаузы, срабатывающей после каждого действия игрока. В большинстве пошаговых игр есть действие "ждать", и зажимая его автоматически, получается реалтайм. Разумеется, в пошаговых играх можно реализовать паттерны посложнее, чем в реалтайме, т.к. у игрока значительно больше времени на анализ ситуации. Т.е. реалтайм по определению должен быть куда более "ограниченным", чем какие-либо пошаговые игры.
>это один и тот же паттерн боя
"Подойти и ударить"? А в реалтайме не так что ли?
>Отряд, не отряд, все сводиться к одной фигне
С отрядом возможно много чего придумать, т.к. тебе разрешено отдать несколько команд за один шаг. В некоторых играх роль "отряда" играют части тела единственного персонажа... типа, в играх про секс...
>>1067805
>тебе придется же корректировать
Такая-то большая проблема, из-за которой нужно обязательно накостылить свой личный велосипед.
Кстати, никогда не видел чтобы приходили вкатунцы и говорили - хочу сессионку, типа доту, кс, танки какие-то.
Стоит задуматься над этим феноменом.
>никогда не видел
>хочу сессионку
Какой же ты невнимательный...
Забил, потому что слишком много работы ради даже минимально играбельного цикла, потом всё это ещё непонятно как балансировать, героев делать тяжело, локации заполнять чем-то и т.д. А в конечном итоге получилась бы какая-то тупая стрелялка - скучно же.
А делать всё с супер-лоуполи графикой неинтересно.
...хотя знаете, щас подумал - а было бы неплохо...
...только если герои будут супер-лоуполиками...
Как принять то, что супер-лоуполи - неизбежность?
>Именно для этого в Godot есть возможность получить абсолютно любую ноду через $-сахар, который ты не должен оставлять в нормальном проекте. Никаких специальных "локаторов" накручивать не нужно.
get_node() - это сервис локатор.
Он выстрелить тебе в ногу через время (та картинка с плохими связами)
DI - залог хорошей архитектуры на будущее.
Нужен если потенциально неизвестны размеры проекта, нужен если постоянно рефакторишь (снижает нагрузку).
Минус небольшой бойлерплейт если инжектишь ручками.
В случае разрастания проекта, можно сделать инжектор или даже IoC.
>Ты не должен пользоваться print настолько часто
Ты опять шизишь, ты раздул этот дурацкий принт, которого вообще НЕ БЫЛО.
У меня там в коде локатор начинается с xx, принта там нет, я просто перечислил имена-маркеры типа zzz, xxx, yyy, //@@@@//, // TODO [2026-01-06-185122]:
> Абсолютно ничего сложного в использовании Godot
Никто не говорил что сложно, ты опять разгоняешь. я говорю что архитектура говно. Для компонентов классно, для кода нет.
> у тебя уже профдеформация
Возможно опыт позволяет определить проблему до того как в нее наступишь.
>Такая-то большая проблема, из-за которой нужно обязательно накостылить свой личный велосипед.
Да причем тут это, я тебе показал связь таймера с камерой, которая казалfсь неведомой. Твои же слова - Камера не существует в игре, бла бла бла.
Ну time_scale относить к тик менеджеру тоже отдельная тема бездарности (простое управление временем норм, но не более).
physics_ticks_per_second вообще лучше не трогать, если не знаешь как трогать правильно, иначе за колайдеры улетишь. То что там тоже есть слово tick - не наделяет его свойством тик менеджера, там свой мир физики.
>А в конечном итоге получилась бы какая-то тупая стрелялка - скучно же.
Это постоянно так, а тут местные говорят - мол делай графоний, потом геймплей. А геймплей потом оказывается - голый.
>Как принять то, что супер-лоуполи - неизбежность?
Да кому не пофиг. Там в соседнем треде Archtower бегает и ни че.
Простой аудиоряд в трейлере - вытягивает всю игру. Какой-то элемент таланта и все, "щелк", игра по другому смотрится. Может у тебя тоже жилка где-то есть скорее всего нет :), просто по кайфу делай
>get_node() - это сервис локатор
>DI - залог хорошей архитектуры
Ты начитался названий паттернов, а по существу не разбираешься. Никто никуда тебе не выстрелит, т.к. созданный таким образом код просто удаляешь и забываешь, когда он тебе больше не требуется. Это основной принцип быстрого прототипирования. Все зависимости будешь внедрять, когда они у тебя в конкретном проекте реально потребуются. Ты вот нормальный прототип сначала сделай, поиграй с ним конкретно как игрок, а не как разработчик, и только в случае, если прототип работает как игра, будешь его переделывать по всем правилам SOLID. А если этот прототип будет неинтересным как игра, то удалишь.
Ты же в школе черновики использовал? Тебя же тоже наверняка учили: пишешь своё сочинение сначала на отдельном листочке-черновике, если надо - делаешь заметки на полях, зачеркиваешь, пишешь меж строк - всякое безобразие, лишь бы написать. Уже потом ты переписываешь сочинение на чистовик, в тетрадку, и сдаёшь учителю чистовик, а не черновик. Так и тут - прототип - "черновики", а игрокам пойдёт "чистовик".
>архитектура говно
>Для компонентов классно
Так "говно" или "классно"? Определись уже...
>определить проблему до того как в нее наступишь
Или шарахаться от своей тени и своих звуков шагов.
>Камера не существует в игре
Да, камера - это сущность движка. Движения камеры зависят от частоты кадров, а не от ускорения времени игрового мира. И если движок по какой-то внутренней причине ускоряет движение камеры, то ты её в её собственном коде должен замедлять. Но это всё не относится к пошаговому моделированию мира - т.е. независимо от скорости мира, камера должна будет перемещаться с частотой обновления монитора.
В 3D камера может быть сложнее, т.к. тебе хотелось бы избегать прохождения камеры через 3D модели, но вот игровые объекты на такую камеру никак реагировать не должны, если это не игра от первого лица... К 2D эти особенности вообще никак не относятся.
>time_scale относить к тик менеджеру
>physics_ticks_per_second вообще лучше не трогать
Да пофиг. У движка есть API - подёргай за него и понаблюдай, как он реагирует. Это ведь не ядерный реактор. Физика в пошаговых играх в принципе не используется обычно (пример на том видео один из необычных вариантов), поэтому тебе от встроенного движка, по сути, ничего кроме _physics_process() и, возможно, редких рейкастов не требуется. Да даже рейкастов не нужно, если вся игра на клеточках...
В общем, ничего не бойся - экспериментируй смело.
>там свой мир физики
...который в твоём проекте не нужен совсем.
>мол делай графоний, потом геймплей.
Там говорили "начни учиться делать контент раньше".
>А геймплей потом оказывается - голый.
В шутеры много кто играет, проблема не в этом. От конкретной концепции плясать дальше некуда, т.е. перспектив для расширения технически мало. Вот, к примеру, тот же Overwatch - ты себе представляешь расширение геймплея за пределы шутера? Там были попытки самих игроков через кастомные бои - очень неуклюжие из-за того, что база игры - просто шутер.
>кому не пофиг. Там в соседнем треде Archtower
Мне не пофиг. Мне не нравится стиль "3D пиксели".
>аудиоряд в трейлере
При чём тут вообще трейлер, если речь об игре...
Мне вообще стыдно за выдуманных персонажей. Т.е. основная задумка вертится вокруг персонажей, если показывать кому-либо, то будет стыдно за них. А вся концепция вертелась вокруг странных персонажей... Безвыходное положение получается. Те же локации налепить из чего попало было бы не стыдно...
>тогда аудитория появится.
Только если проект дойдёт до публикации где-либо.
>Для себя. Без оглядки на кого-либо.
Честно говоря, это не совсем правда... В смысле, я каждый раз вынужден сдерживать себя от совсем уж бредовых, странных или неприличных идей, и если бы я действительно делал "без оглядки на кого-либо", то все мои проекты быстро скатывались бы в NSFW, и я бы такое уже точно нигде бы не публиковал, тем более здесь. Но я не могу просто работать в стол, мне нужен какой-то отклик...
Но, конечно, я хочу сделать игру, в которую мне самому будет интересно играть - и хочу потом играть в неё. Поэтому я склоняюсь к жанру выживалки с условно-бесконечным геймплеем, процедурной генерацией и т.п.
В результате на днях я опять самодемотивировался... Мне давно нужно было как-то "стандартизировать" поведение островов, чтобы они вели себя предсказуемо (и был единый шаблон для создания новых островов). И у меня давно вертелась мысль, что у островов должны быть основные элементы и второстепенные. Вот я нарисовал схемку, чтобы не забыть идею, и даже вдохновился этой схемой, но когда накидал в движке (оказалось, почти всё уже было готово, я просто забыл) и стал тестировать... Я понял, что в этой механике самой по себе вообще никакого фана нет. Ну вот нет никакого смысла, это просто фича без цели. Нет, может быть, она будет полезна в полноценном геймплее, но его у меня нет, чтобы было можно проверить...
И тут я понял, что я снова прокрастинирую работу с контентом - 3D модели хотя бы, текстуры, анимации. Мне скучно с серыми кубами, скучно с рябящей тайлами текстуры, скучно от одних и тех же плейсхолдеров, размноженных несколько десятков раз в маленьком клочке пространства. Как я вообще должен отлаживать "фановый геймплей", если я вижу на экране один и тот же ассет-затычку и это вызывает у меня желание больше никогда его не видеть, как и проект в целом?..
С другой стороны, я понимаю, что слишком рано флудить декоративным контентом. Что толку от нескольких вариантов текстур и мешей, если базовые механики глючат или совсем не работают? И если уж заниматься контентом, то нужно заниматься в первую очередь персонажем, вокруг которого строится вся игра... Но её переделывать нужно - там всё слишком криво... и я даже не знаю, какие пропорции делать (см. выше про самоцензуру и слишком бредовые идеи)... Изначально я пытался сделать "что-то среднее", чтобы потом шейпкеями настраивать из игры (кастомизация), но сейчас думаю, что это будет слишком сложно.
Да, кстати, я наконец-то понял, почему кто-то её здесь "раскорячкой" называл - у неё кости кривые. Я как-то совсем не обращал внимания, сделал и сделал - а на днях искал способы ригинга и обнаружил, что кости ног должны быть ровными, как две палки - а у меня они выгибаются наружу почему-то. Нужно переделать...
И ещё меня снова порывает в сторону чего-то другого, типа "тренировать нейронку для чатбота (в Godot)"...
>>1067836
>Но мне нужна база для этого, чтобы геймплей не завернулся в тупик через пару часов игры.
Возьми базовый геймплейный цикл жанра survival и можешь вращать его до бесконечности:
>The core gameplay loop in survival games typically involves three main actions: harvesting resources, crafting items, and engaging in combat or exploration. This loop keeps players engaged by providing a cycle of gathering materials, creating useful tools or items, and facing challenges in the game environment.
Вместо "crafting items" может быть "building vehicle", это тоже относится к жанру survival.
Лично я начал с конструирования дирижаблей, выгорел из-за непредвиденных сложностей, переключился на острова, снова выгорел, переключился на персонажа - сделал верёвку и примитивные анимации... и теперь не могу сдвинуться с мёртвой точки. Но более классический survival было бы куда проще сделать, это просто я собрал в одну кучу все нетривиальные механики и идеи, которые меня когда-то привлекали.
Так что, если тебе реально нужна только "база для расширения" - делай survival и не парься. Туда можно что угодно прикрутить, даже стратегию и гонки, т.к. этот жанр по сути - "симулятор жизни в бесшовном мире".
> Да, кстати, я наконец-то понял, почему кто-то её здесь "раскорячкой" называл - у неё кости кривые. Я как-то совсем не обращал внимания, сделал и сделал - а на днях искал способы ригинга и обнаружил, что кости ног должны быть ровными, как две палки - а у меня они выгибаются наружу почему-то. Нужно переделать...
Ни в коем случае не переделывай. Ты уловил неповторимый стиль. Держись за этот стиль. Он приведёт тебя к успеху.
И еще интересно, откуда в островах берутся сундуки? Это как-то объяснено лорно на данный момент?
> и стал тестировать... Я понял, что в этой механике самой по себе вообще никакого фана нет. Ну вот нет никакого смысла, это просто фича без цели. Нет, может быть, она будет полезна в полноценном геймплее, но его у меня нет, чтобы было можно проверить...
> И тут я понял, что я снова прокрастинирую работу с контентом - 3D модели хотя бы, текстуры, анимации. Мне скучно с серыми кубами, скучно с рябящей тайлами текстуры, скучно от одних и тех же плейсхолдеров, размноженных несколько десятков раз в маленьком клочке пространства.
И вот по этому фрагменту я хочу ещё раз напомнить тебе, ты наверняка видел, но забыл, видосы ранних билдов игор крупных студий, я могу навскидку вспомнить нотидог с анчартедом и юбисофт с ассасинами, где на фоне грейбоксового уровня у них скакал полностью проработанный игровой персонаж.
То есть, я хочу отдельно проговорить эту мысль, практика студий с реальными играми показывает, что персонаж - это главное. Персонажа следует анимировать и механировать полностью и детально на ранних этапах разработки, а окружение уже потом лепится под готового персонажа.
То есть, я в третий раз хочу отдельно прояснить тот факт, что основной видеоигровой фан который мы можем получить, происходит от механик и таймингов контроллера персонажа. А затем уже отталкиваясь от своего отточенного персонажа, ты конструируешь окружение, уровни по метрикам и всё такое.
>Никто никуда тебе не выстрелит, т.к. созданный таким образом код просто удаляешь и забываешь, когда он тебе больше не требуется.
Ты путаешь прототипирование со стартом говно-проекта, который ты делаешь, делаешь и приуныл забросил. Прототипирование может перерасти в нормальный проект.
>А если этот прототип будет неинтересным как игра, то удалишь.
Да ладно, ты реально будешь советовать то что я делаю? Спасибо
>Так "говно" или "классно"? Определись уже...
Я же прям там же пишу для компонентов идея хорошая, для организации кода ужасна.
>Или шарахаться от своей тени и своих звуков шагов.
Невыдуманные истории о которых невозможно молчать.
>Да, камера - это сущность движка.
И пошла отмазка с шизой и еще еще пошаговый мир, привнес, когда мы говорим про реалтайм игру с тик менеджером. Сам нафантазировал, сам по возмущался.
> т.к. тебе хотелось бы избегать прохождения камеры через 3D модели, но вот игровые объекты на такую камеру никак реагировать не должны
Ооо еще наверни, давай уже в 4D пойдем. Зачем объектам реагировать на камеру? Сам придумал, сам по возмущался.
Кстати, камере тут уже надо знать об объектах, то есть камера уже не оторвана от игры как ты фантазировал
Ты точно игры пишешь?
>В общем, ничего не бойся - экспериментируй смело.
Ну да, мы тут сидим боимся прям
>...который в твоём проекте не нужен совсем.
Ого, спасибо, так вот почему у меня нет коллайдеров. Спасибо.
Как же приятно, когда тебе же объясняют как устроен твой проект. Хорошо что с камерой мы разобрались. И не один _physics_process не пострадал.
>Там говорили "начни учиться делать контент раньше".
Советы уровня. Ты документацию читай, рисование практикуй, зубы чисти, слабых не обижай.
>Вот, к примеру, тот же Overwatch - ты себе представляешь расширение геймплея за пределы шутера? Там были попытки самих игроков через кастомные бои - очень неуклюжие из-за того, что база игры - просто шутер.
Ты думаешь в компании такие сидят и говорят - братаны, мы уперлись в шутер, мы проиграли эту битву идей, уходим.
Компании срать, они сделали концепт и ждут сливки. Бездушный продукт на полке. А игрокам что? Игроки хотят углубить игру, продолжить её. В этом весь феномен мододелания.
Ты видишь что в игре что-то не хватает, а менеджеры так не видят, там все хорошо.
У нас тут разные векторы игростроя. Какая-то часть пилят игру с душой позиционируя ее как игру от игрока для игрока. Зачастую на этом обжигаются, сделать иммерсионную игру это самое сложное в геймдеве. А повторять игры это просто, бездушный конвейер инвесторов. Поэтому те кто вам в качестве идеи предлагают повторить игру, а не творить свою - глупцы. гоните их насмехайтесь над ними
>Возьми базовый геймплейный цикл жанра survival и можешь вращать его до бесконечности:
Как только ты решаешь проблему с едой или безопасностью - пропадает антагонист в игре.
Это фатальная проблема выживача. Ты не можешь бесконечно затягивать выживание и ты сидишь ищешь нового антагониста, когда игрок вдоволь пописол/покакал.
Выживач, это больше иммерсионный "дополнитель", который не должен раздражать в игре, чем база.
>И еще интересно, откуда в островах берутся сундуки? Это как-то объяснено лорно на данный момент?
Другой анон. Попытка слепить все и вся. Зельду и скай-фай. Насколько я помню это газовый гигант и научная фантастика. Не делай сундуки - делай поиск инопланетных артефактов прото цивилизации инопланетян. Или выкини скайфай и сделал фэнтезийный зельдо/геншин мир. Разрыва шаблонов стоит избегать (ты рвешь иммерсивность).
Не бойтесь дропать проекты (или временно от них отходить), так люди к шедеврам и приходили. Да, чувствуешь себя как портовая леди - но это фигня, главное что - главное чтобы по кайфу было.
>>1067880
Нет все просто
Базовая кор механика игры - которую будет делать игрок 90% времени должна быть отполирована до блеска. Не важно какие у тебя квесты или красивый мир или красив игрок. Если боевка вялая, не отзывчивая - ты потеряешь игрока. Тоже самое с сундуками - если это кор механика как в геншене, то сундуки должны дополнять исследование опенворда, поиск сундуков по лабиринтам через анус под островами - могут быстро утомить.
Понятно что если ты делаешь паркур-нинзя-боевку - то это кор механика, ты обязан начать с ней. Но если это просто классический лутер-шутер, сделай ты эту капсулу с прямоугольником в виде оружия и все. Переключись на главное в игре - в кого ты будешь "шутерить" и где (и как) ты будешь лутовать"
Ты уже продюсером игры стал? У чела стимпанк, а не сайфай. И не Зельда это А скорее биошок. Нахуя ему концепт переделывать, чтобы что? Даже если не стимпанк, то какая разница? Вон в скайриме роботы и колдовство никак игре не помешали. 15 лет наяривают паровых андроидов с заклинаниями.
Попробуй заморозить проект и просто помечтать о ново концепте.
Смотри "психологию". В выживаче мы отождествляем себя с героем и чем более привычная местность - тем сильнее это погружение. Мы не часто бывает на островах юпитера и поэтому жарить окорок на газовом гиганте смотрится как-то поверхностно, не естественно.
А теперь представь себя в лесу, где ты находишь разбитую хижину и прячешься от дождя, разводишь костер и слышишь в ночи страшные звуки. Тут пропадает уведомление о холоде, но появляется новое о голоде, а у тебя последняя консерва.
Внезапно весь твой мир скукоживается до мысли "где взять" еду, как не сдохнуть ночью от существ или мороза.
Уже другая атмосфера, согласись?
Я к чему - нравится выживач - развивай идею. Не пытайся прикрутить "выживач к гонкам". Да, я сказал что выживач быстро теряет антагониста - будь готов прикрутить что-то рядом (но не гонки).
>Ты уже продюсером игры стал?
Нет, скорее я стал двачером.
>Вон в скайриме роботы и колдовство никак игре не помешали
Ну во первых они там лорно обоснованы примитивны, не нарушают дарк-фентази и средневековье. Они пересекаются не сильно и в тоже время достаточно чтобы не казаться чуждым.
Как прикрутить выживач к стимпанку на газовом гиганте в зельда сеттинге - ну тут хз. Надо либо натянуть сову на глобус либо же менять что-то.
>>1067896
Гномы технари, в легком техническом сеттинге стимпанка смотрятся в фэнтези давно хорошо.
А теперь попробуй в скайрим натянуть пехотинца с винтовкой M16. Будет сложновато.
Это тонкая грань между креативом и шизофазией.
Поэтому если ты все же хочешь натянуть винтовку в фэнтэзи игру, тебе придется ее деградировать до "палки стрелялки" ядрами
У меня такие же круги были перед глазами, когда я перепил на новый год, а потом я очнулся в повозке.
Ну если прикрутить сбор мусора для летающих тарахтелок, то это нормально сочетается с "газопанком" и сундуками. Предстать жанр стимпанк, графон в стиле зельды, аркадные механики, лут для постойки летательных аппаратов. Можно добавить смешных NPC типа смурфов. Они будут квесты давать. Смурфики наполняют газовые шары. Это основа стабильности в мире. В облаках мир Создателя вселенной. Далеко внизу огненный мир Разрушителя. Мейн квест - злая ведьма отобрала газ у смурфиков. Теперь без весь мир рискует попась в мир Разрушителя. Надо победить ведьму и вернуть газ.
Зы
Еще не обязательно сбор мусора делать напрямую связанным с мейнквестом. Мусор нужен для постройки дирижаблей. Дирижабли ломаются, но они нужны чтобы собрать магические кристалы по миру. Необходимо собрать скажем дюжену кристалов чтобы шаман смурфов уничтожил барьер которым злая ведьма окружила свой замок.
А теперь прогони это у себя в голове и подумай - зацепила бы тебя такая игра? Не потому что ты придумал, а просто со стороны посмотри.
Ну типа высосать сюжет не сложно, нафантазировать мир тоже, даже занять игрока крафтом дирижаблей, едой и прочим.
Ты как бы в это собрался вкладывать тонну человеко-часов.
Единственный момент который меня бы действительно зацепил.
-Дирижабли можно апгрейдить до больших размеров.
-Дирижабль есть твоя база и дом
-Бесконечное путешествие по разным мирам (оторвать от газового гиганта, спустить до фэнтэзи миров).
-Ты покупаешь в городе карты/берешь квесты. За счет карты/квестов летаешь в миры, гриндишь, файтишься, лутаешь
-Возвращаешься в города - продаешься, апгрейдишь, сычуешь в своем доме-дирижабле.
>-Возвращаешься в города - продаешься, апгрейдишь, сычуешь в своем доме-дирижабле.
Наверняка есть такое аниме, я прям уверен (не смотрю аниме, но уверен что в этой версии вселенной должно быть такое аниме)
А как зе элдер скролс устроены? Хочешь ловишь жемчуг. Хочешь мейнквест выполняешь. Где тут противоречие. Я отвечал на вопрос про то что якобы масло с водой не смешивается. Оказывается никакого масло и воды. И все нормально сочетается
Как минимум я арты нашел
Для инди это не реально сделать так чтобы цепляло. Да даже большая компания недавно обостралась с бесконечными мирами помянем Страфилд
Только скайрим создает такой мир в котором ты хочешь жить. Окружение, музыка, все детали итд. Добавь в скайрим синих гномиков или паровозик томас и все - нет у тебя иммерсивности, просто одной фигней помножил на ноль.
Это тонкая грань чтобы удержать погружение (а еще создать это погружение).
>Для инди это не реально сделать так чтобы цепляло
Сделай процедурную генерацию на базе заготовленных регионов (регионы руками, мир процедурно). Зарелизь и сиди пукай длс 10 лет, пили новые миры и истории.
Помоему ты бредишь. Как почему в средневековом фентези можно лутать сундуки, а в стимпанке с синими гномами нельзя? Сброр кристалов нормально обосновывает лут и постройку дирижаблей.
Тут арчтовер критикуют за каждый новый этаж сделаный вручную
Карта и пещеры из тонны повторяющихся элементов. Какой-нибудь крафт в кузне ты сделаешь за день (щелк и предмет лежит, даже анимации нет). UI там как-будто альфа версия, тупо список.
Горы ланшафт + повторяющиеся блоки скал. Махать мечем не долго, лук чуть сложнее.
Или ты хочешь сказать что лично тебе нравятся викинги и не нравится паравозик томас? Ну так игру не лично для тебя делают. Тебе может аниме еще не нравится (как и мне) но тем не менее миллионы смотрят.
Ну когда ты сказал игроку - тут лоу графика, игрок ждет качество в другом.
Просто автор арчтовера не додумался до механики показа трусов как автор газового мира.
Разница между нами в том что я пытаюсь понять почему так происходит.
Геймдев это в первую очередь психология игрока.
Почему паровозик томас это веселый мод на поржать на 10 секунд в то время как какие-нибудь моды на дома/особняки - сотни их, с обзорами разных стримеров и прочим.
У меня вообще афантазия, я половину не чувствую что чувствуют игроки.
В любом случает индюк Скайрим/Асасина не сделает. Все возможности что есть у одиночки - это сделать аркаду, рогалик, платформер, квесты и процедурная генерация. Вот это и надо использовать в своих инди играх.
Кроме числа квестов что там тебя напугало?
Там очень много переиспользуемых моделек.
Ты не сможешь на голый террейн натянуть камни?
Влети в гору и посмотри о чем я. Вы на анимешные юбки тратите больше времени. Там буквально за скалы прячут ландшафт, чтобы меньше работы было (кустики цветочки).
Все правильно делают. Чем больше переиспользований всего, кода, моделей, тем меньше весит игра, тем меньше потенциальных багов, тем меньше приходится разрабатывать ненужную хуйню, которую никто не заметит.
- Игра хороша, но короткая, прошел за 2 вечера, 3 звезды
- Игра хороша, но заброшена, никаких обновлений уже полгода, 2 звезды
Игра сюжетная, игра бесплатная, игра законченная, автор сказал что хотел, все, хуле вам надо. Будто люди окончательно подсели на бесконечный лайвсервис и ловят синдром отмены.
Игра на годоте.
https://www.esol.com/press/press_190.html
https://www.w4games.com/blog/w4-games-news-1/esol-and-w4-games-partner-to-bring-godot-to-industrial-and-enterprise-applications-124
Вот тут годот рассматривают под энтерпрайз, реалтайм, индустриальные, кибер-физические и встроенные системы.
Представьте что мы стоим у истоков нового RAD IDE которое будет использовать весь мир. И такие, чтобы поделать?
>мы
Кто мы-то, кто мы? Твоих коммитов в годоте много? А моих?
Чтобы стоять у истоков необязательно в них ноги полоскать.
твоя игра в каком-то смысле на raft похожа. вода = воздух, острова = острова. raft очень фановый из-за акулы (всегда есть опасность по умолчанию) + ощущение расширения базы.
добавь какую-нибудь злую птицу + лут на островах для дирижабля, затем демку ебани.
>>1067992
Будущее за попенсорс. Либо хрюнити и урины откроются под норм лицензии. Либо годот и ему подобные сожрут их.
Таков путь
Линупс победил виндофон на телебонах
Линупс победил юникс на серверах
Блендер победил пиратство 3дмаксов
Опенсурс языки программирования победили дельфи
Веб на 99% как опенсурс победил закрытый десктоп
Но на самом деле если бы не было опенсурса в таком бешеном количестве, щас бы на ламповом дельфи писали за большие бабки, а нейронки бы заметяли только бухгалтеров и такистов
>>1068026
ИИшка пока еще нефига не может. Потому что она не понимает. А мы все еще не понимаем как понимать. "Коробочка - рожай продукт" не получится.
Чем сложнее код, тем сложнее будет тебе вайбкодить. В итоге тебе нужно будет миллион итераций вайбкода, чтобы сделать что-то простое не сломав старое (для сложной системы).
Скорее всего все закончится тем, что появиться какой-то нейро-язык программирования, который будет проще, но это будет все равно программирование (причем еще со вставками из обычного дедовского императивного языка, потому что нейронки всегда будут "вероятностными").
>И какой попенсорс хоть что нибудь победил?
Гитхаб видел? Сейчас писать софт это буквально склеивание опенсорс либ.
Там колоссальное влияние на современную айтишечку, если бы не это все, сидели пропукивали говноподделки как в 90, да еще за подписку, в платном браузере, с тонной багов, на которые всем насрать (у тебя конкуренция между жопой и говном).
Скорее всего код с моделькой и логикой намертво прибиты друг к дружке. И проще сделать так.
А вот читали бы в беседке доки, то знали бы что можно $ShelfMesh.hide()
Срочно исправить и выпустить новый Skyrim ShelfHide Edition!
>Линупс победил виндофон на телебонах
Спасибо гуглу и китайцам, а не опенсурсу
>Линупс победил юникс на серверах
Не победил
>Блендер победил пиратство 3дмаксов
Те кто раньше не нёс деньги не стали их нести. Индустрия как была на майе и 3дс макс так и стоит, на блендере дюжина поделок от леваков для диснея и блендер чуть пиздой не накрылся не так давно, в оставку ушёл основатель всей херни (30 лет боролся с 3дс макс), а проблемы с деньгами были уже более года, он ещё поживёт, но не факт что долго.
>Опенсурс языки программирования победили дельфи
Делфи не был популярен нигде кроме СНГ и умер потому что стали переходить на web софт, его скорее победил Go и C#, я как бывший делфист говорю.
Ровно как mysql не победил oracle, а postgres заимел аудиторию из-за похожести на oracle и отсутствии анальных ограничений в лицензии.
>Веб на 99% как опенсурс победил закрытый десктоп
Делать красивый интерфейс всегда было морокой, простой интерфейс корпорации не интересовал поэтому они заюзали возможности html+css для UI и опенсурс тут ни каким боком. В итоге у тебя и стим и телеграм и вся остальная херня держит 50 потоков, 10 процессов и периодически тормозит потребляя гигабайты оперативки. Найс победил.
>>1068026
>Но на самом деле если бы не было опенсурса в таком бешеном количестве, щас бы на ламповом дельфи писали за большие бабки, а нейронки бы заметяли только бухгалтеров и такистов
Копиум очередной, ты ещё скажи что оперсорс опбедил 1С, кек
А теперь купил мощный комп на заработанные играми деньги?
>float, но формально JSON имеет только "number"
В js нет int (кроме определённых случаев, но ты не вытащишь этот тип никак).
>но как только начинаешь размер править - сразу две формы меняются (пофиксили вроде в бетке) - неочевидное поведение
Поведение неочевидное только для того, кто не знает/не понимает как работают ресурсы в годоте (спойлер, при копировании ноды с ресурсом - нода-оригинал и нода-копия будут обладать ссылкой на один и тот же ресурс, а форма коллайдера это тоже ресурс), и я всецело подобное поведение одобряю.
Вообще конечно всё это неочевидно только если не читать справку, если всего-навсего прочесть основной гайдлайн, даже не углубляясь в классы - всё это станет понятно.
> postgres
Нахуя так писать? Как же бесят подобные анальники со свими коверканиями.
Вкат пробуют по видосикам, гайдикам с примерами, потом начинают тыкать сами и натыкаются на не интуитивное поведение. Такова реальность, хочешь ты этого или нет, никто не начинает с доков. Но читать доки надо.
Нормально делай, нормально будет
https://www.youtube.com/watch?v=11_AY9ACfJA
4.6 beta 3, слышь тести чтобы потом про регрессии не ныть.
А да, трах с синглтонищем Input с Гуями, это отдельная премия.
Во всех гайдах дергают это животное, мина замедленного действия, благо гуглиться быстро.
Вроде простое лоуполи, но красивое. Как это достигается? Постобработкой? Научите.
Очень полезная информация, верни мне мой тысяча девятьсот девяносто седьмой.
Неплохой чувак, вот ещё посмотрите, как он ловко систему статов построил, с заделом на будущее усложнение
https://youtu.be/vsBb9921GfA
>Нахуя так писать? Как же бесят подобные анальники со свими коверканиями.
Не хрюкай
Какую версию Godot используешь?
В целом - такого рода косяки ожидаемы даже в платном софте, ничего необычного. Самые "страшные" ошибки в Godot были, когда ты мог случайно поломать себе сцену так, что Godot вообще её не может открыть из-за неправильной информации в .tscn, и тебе приходилось фиксить свой косяк в текстовом Блокноте, пытаясь разобраться в тонкостях формата. А если сохранил в бинарный .scn и сломал - всё, делай с нуля... Но они уже давно пофиксили такие проблемы, или, по крайней мере, я давно на них не напарывался. А бинарный формат используется автоматически при экспорте игры, поэтому сохранять в .scn вручную больше не нужно (только если у тебя там гигантские массивы типа тримеш коллизий, но такое лучше сохранять в отдельный от сцены .res файл). Да и если ты делаешь частые бекапы и/или коммиты в систему контроля версий, то даже такие ошибки не были большой проблемой.
>ебейшее кол-во багов в двигле, которые мешает работать
Не так-то их и много, и большинство самых раздражающих фиксят довольно быстро.
>При рекурсивном открытии всяких вкладок с настройками в инспекторе всё двигло фризит.
Что значит "рекурсивное открытие"? Никогда с таким не сталкивался. Ты вложил А в Б, Б в А, А в Б...? Циклических зависимостей вообще лучше всего избегать, а Resource/RefCounted в принципе не рассчитаны на циклические зависимости (нужно использовать WeakRef, если тебе очень сильно нужен такой цикл с RefCounted объектами, иначе движок не сможет их удалить из памяти автоматически и может получиться "утечка памяти" в коде игры).
>Вкладка материалов скачет и не дает попадать по кнопкам с первого раза.
С этим я тоже ни разу не сталкивался или не помню. Может быть, у тебя шейдеры сохраняются на диск? При первом изменении некоторых настроек материала компилируется новый шейдер, из-за чего GUI редактора может подвисать на секунду-две на слабых ПК. Но потом этот шейдер считывается с диска и никаких зависаний или рывков у тебя быть не должно. На мощном ПК это, скорее всего, не будет заметно.
>Еще иногда вылеты происходят при фиксированных действиях.
Что за "фиксированные" действия? Да, изредка бывают вылеты - нужно почаще сохранять сцены и скрипты. Однако, в большинстве случаев эти вылеты из-за каких-то твоих ошибок в @tool-скрипте, либо из-за неких сложных манипуляций с деревом. Но, если я правильно помню, они уже пофиксили большинство вылетов, которые возникали из-за манипуляций с деревом сцены.
>А еще если вывести файлменеджер в отдельное окно то драг энд дроп отваливается.
У тебя два монитора что ли? Проблема есть, да, но большинство используют однооконный режим.
>ошибки отсутствия Joint'ов когда в дерево попадает SpringBoneSimulator3D
Скорее всего, это из-за недавних нововведений, так что должны скоро пофиксить. Можешь залезть в исходники и вырезать assert, который спамит этой ошибкой, и сбилдить кастомную версию движка.
>>1068070
>Чтобы получить доступ к свойствам ресурсам, надо кликнуть по нему - вообще неочевидная штука.
Глупости какие-то... Ресурс чётко подсвечен как "кнопка". Нужно просто понять, что в этом GUI - "кнопка".
>сразу две формы меняются
Да, тоже с таким сталкивался, но тут дело вот в чём - ресурсы специально разработаны для того, чтобы их часто повторно использовать, и когда ты дублируешь ноду, ты по умолчанию хочешь использовать тот же самый ресурс. Если тебе нужен отдельный ресурс - ты его дублируешь. Это неочевидно, но на самом деле намного удобнее, т.к. в противном случае ты был бы вынужден вручную сохранять каждый диск в отдельный файл и потом указывать этот файл в настройках разных нод. В 4.6 добавили кнопку-иконку, которая отмечает, когда ресурс не является уникальным, и позволяет быстрее сделать его уникальным.
>Сцена (файл) может в себе иметь ресурсы, скажем какой-то tileset или даже скрипт файл.
Это очень большое преимущество для мелких ресурсов и мелких скриптов. Делаешь сцену и все её "персональные" ресурсы пакуешь в один файл. В отдельный файл имеет смысл сохранять только то, что планируешь использовать в разных сценах - как, например, скрипты с class_name или общие ресурсы.
>_ready - это не вызов когда все готова перед кадром
Нет, _ready - это именно ready, т.е. "я готов" - но "я" в данном случае - это "ветка дерева" или "сцена", и готова она может быть лишь в одном случае - когда готово всё, что в неё "входит". Это логично и тоже удобно, когда ты принимаешь философию сцен движка и оперируешь "ветками дерева" как самостоятельными объектами (дети-ноды являются частями более крупного объекта-родителя и поэтому обязаны быть готовы до готовности родителя; это как эмбрион обязан сформировать рабочее сердце, мозг и другие органы до того, как он сможет родиться на свет; или как вагоны длинного ж/д состава должны быть готовы до того, как локомотив сможет начать двигать их с места).
>без последующего спуска
Первый _process может быть только после _ready, и начинается он сверху дерева, спускаясь вниз. А также вниз спускаются _enter_tree, но до _ready. Так что спуск вниз легко организовать самому, но если ты используешь концепцию "веток дерева, готовых к работе", то спуск вниз тебе обычно не нужен.
>>1068072
>ты не вытащишь этот тип никак
Некоторые JSON-парсеры различают "1" и "1.0" как разные значения, например, Steamworks API в некоторых ситуациях ожидает целое число без ".0" и если встречает это число с ".0", то игнорирует это значение как некорректное, используя заданное значение по умолчанию. На GitHub уже описывали эту проблему - что нельзя приписывать ".0" к рандомным JSON, т.к. это ломает совместимость со сторонними парсерами. Ты можешь сказать, что это чужие парсеры виноваты, что не соответствуют спецификации JSON, но их таких много, и ты не заставишь их все прям сейчас взять и начать игнорировать эти лишние ".0".
>>1068096
>но красивое. Как это достигается?
Там правильно выбрана палитра (это главное), включён bloom и, кажется, ambient occlusion.
https://docs.godotengine.org/en/stable/tutorials/3d/environment_and_post_processing.html
Палитру можешь найти в интернете, но вообще-то это целая наука (несложная);
https://ru.wikipedia.org/wiki/Колористика
>>1068144
Ой, да ну его нафиг, он сначала учит, а потом говорит "простите, был виноват" (про конечные автоматы).
Вот туториал, который тебе нужен:
1. ВНИМАТЕЛЬНО читаешь документацию.
2. Делаешь ПРОСТЫЕ игры из 1-2 механик.
3. ДОДЕЛЫВАЕШЬ до играбельной версии.
4. Повторяешь до достижения игры мечты.
Всё остальное приведёт тебя к "tutorial hell".
>Игры делай
Я отдыхаю от делания игр.
>>1068146
Более читабельный вариант.
>Некоторые JSON-парсеры различают "1" и "1.0"
Лучше избегать такую магию. Тебе так сильно нужен текстовый читаемый формат при сериализации? Есть xml, да он жирнее, но тебе же не нужно данные по сети передавать.
А лучше вообще в бинарь.
>Там правильно выбрана палитра (это главное), включён bloom и, кажется, ambient occlusion.
Мне показалось какое-то матовое свечение, но я не разбираюсь. Как-будто с материалом как-то поработали.
> Делаешь сцену и все её "персональные" ресурсы пакуешь в один файл. В отдельный файл имеет смысл сохранять только то, что планируешь использовать в разных сценах - как, например, скрипты с class_name или общие ресурсы.
Ну где работает это, а где нет (с формами коллайдера) в итоге путаница. А были бы ресурсы всегда отдельно, пришло бы сразу понимание, что вот он отдельно лежит.
В общем, "явное" тут важнее малого удобства.
>Мне показалось какое-то матовое свечение, но я не разбираюсь. Как-будто с материалом как-то поработали.
скорее всего дело в этом ambient occlusion.
>Тебе так сильно нужен
Сам почитай, что и кому нужно:
https://github.com/godotengine/godot/issues/105160
Я на этот иссуй вообще случайно попал из поисковика. Цитата оттуда:
>Godot will edit my item definitions adding unnecessary .0's changing my integers to floats breaking the schema for Steam inventory service.
Пруф того, что Steam ожидает от тебя "integer":
https://partner.steamgames.com/doc/features/inventory/schema
Ошибка ли со стороны Steam игнорировать числа с ".0" в JSON? Возможно. Но Steam вряд ли это поменяет.
Ошибка ли со стороны юзера хранить этот JSON в папке проекта? Возможно. Но это неочевидный нюанс.
А главное - в Godot 3.x такой проблемы не было, Godot 3.x не перезаписывал твои JSON в папке проекта.
>так сильно нужен текстовый читаемый формат при сериализации
Лично я несколько раз рассматривал возможность вручную писать JSON в качестве настроек некоторых частей проекта, чтобы не создавать избыточное количество .tres-файлов. Но в результате решил, что JSON вручную писать неудобно, даже если бы я писал его в формате HJSON и компилировал потом... Как ты считаешь, XML проще писать вручную, чем JSON? Сомневаюсь.
>>1068158
>какое-то матовое свечение
Если ты имеешь в виду цветное свечение - поиграйся с настройками Glow в Environment (bloom), это на 99% оно.
Если ты имеешь в виду чёрные края на стыках кубиков - это Ambient Occlusion, скорее всего, SSAO в Environment.
В Godot много эффектов, отключённых по умолчанию из-за того, что они сильно нагружают видеокарту.
>>1068159
>с формами коллайдера в итоге путаница
Путаница у новичка. Если тебе дать дрель и ты себе ногу просверлишь - это дрель виновата или ты сам?
>>1068160
Хочешь - делай. Чем быстрее начнёшь, тем раньше что-нибудь начнёт получаться.
>>1068146
Блять ты можешь не писать такие посты, отвечая не десятки постов одной простыней? Пишешь по делу, но невозможно читать и выискивать чего там кому, скролля внутри скролла.
> вручную писать JSON
> XML проще писать вручную, чем JSON?
А если писать через специализированные редакторы? Для жсон я нашёл json editor online (который надо правда нынче один раз скачать себе в кэш браузера через родственников в Голландии). Для XML есть вполне неплохой XMLNotepad который раскладывает XML в удобный древовидно-гридовый вид.
>Вот туториал, который тебе нужен:
>3. ДОДЕЛЫВАЕШЬ до играбельной версии.
У тебя нет лимитов на проект. Просто делаешь новый проект, повторяешь какие-то вещи, дропаешь, новый проект, повторяешь, дропаешь. Параллельно у тебя лежит один или несколько "нормальных" проектов мечты, которые ты дополняешь по мере возможностей.
НЕ НУЖНО каждый выпук и каждый гайд доводить до релизного состояния.
У местных какая-то травма, что нужно обязательно выпустить свой шлак, иначе демоны релиза тебя покарают в отместку. Тем временем рутина, которую ты уже знаешь только понижает мотивацию.
Единственно, где реально важно показать, что ты делаешь и заканчиваешь демо-игры, это внимание пары местных малолетних шизиков в разделе движкосрача/ньюфагосрача. Очень важно перед ними показать что ты не безигорка, очень. Это суть геймдева.
Может, тебе стоит прекратить писать 10 постов подряд, отвечая по отдельности на каждый абзац? Это не чат.
>скролля внутри скролла
Это проблема твоего браузера... Обычно ссылка на твой пост помечается (You), так что ответ легко найти.
А в некоторых разделах почти каждый анон большими постами друг другу пишет... 15к символов - МАЛО.
>>1068165
>А если писать через специализированные редакторы?
Я хотел именно текстовый формат. Если бы мне нужен был редактор, я бы и сам свой сделал на Godot, либо воспользовался инспектором Godot для tres файлов. Проблемы всех таких редакторов в том, что просто взять и скопипастить целый фрагмент текста нельзя, что-то поменять - нужно или мышкой, или табами переключаться; часто нет адекватного "поиска и замены", что для простого текста реализовано даже в самом простом Блокноте; зачастую ими неудобно пользоваться с телефона (иногда записываю что-то на телефоне). Да и тот же JSON не гарантирует порядка сохранения данных в файле, т.е. нельзя всё вручную отсортировать и потом сохранить этот порядок. Это причины, по которым мы до сих пор пишем почти весь код в текстовом виде, а не составляем его из блоков как в каком-нибудь Scratch или соединяя ниточками прямоугольные блоки. Но в итоге я решил, что нечего велосипед выдумывать - нужно использовать то, с чем проще всего начать работу (tres + инспектор Godot), а уже потом можно будет перебраться на какой-то другой формат, если вдруг понадобится.
>>1068166
>>3. ДОДЕЛЫВАЕШЬ до играбельной версии.
>доводить до релизного состояния.
"Играбельный" не равно "релизный". Играбельный - это то, во что можно поиграть и выиграть или проиграть, или просто получить удовольствие от игры. Для релиза нужно сделать массу всего, что простой "играбельности" никак не касается. Для примера, если твой персонаж в платформере не умеет прыгать на платформы - это неиграбельно. Но даже если твой персонаж в платформере бегает и прыгает, это не означает, что игра готова к релизу - ты же не прикрутил ребиндинг клавиш, туториал, таблицы рекордов, авторизацию через соцсети, рекламный банер какой-нибудь и всё такое. Но поиграть можешь - это главное.
В остальном согласен с тобой - не нужно выпускать каждый проект как игру. Это лишняя трата времени и сил. Даже если какой-то случайный проект может случайно "взлететь", шансы такого исхода микроскопические - на каждый Flappy Bird приходятся сотни тысяч никому неизвестных проектов, которые даже с неплохим геймплеем и приемлемой графикой не "взлетели".
>Сам почитай, что и кому нужно:
Я еще не добрался до сериализации, будет плохо если нет инструментов для xml.
Я бы выбрал бы нечто такое:
godot - xml // для себя
godot - xml - json // для чужого api на json'ах
Да, годот не должен искажать данные, number это специфичный тип, а не чистый float. Он может быть представлен int.
>Путаница у новичка. Если тебе дать дрель и ты себе ногу просверлишь - это дрель виновата или ты сам?
Ну я сказал неочевидно поведение, если бы годот не прятал ресурсы в себе, такого бы не было. Что мусолить тему, да еще дрочить аналогии.
Это не делает годот плохим, есть у анальников такое "шоу" на конференциях - как паззлеры, там показывают код - спрашивают что он делает - а потом оказывается поведение вообще не то которое ожидали.
Что это говорит? Что косяки есть везде. Только годот может пофиксить, а язык уже прибит сам к себе по-дизайну.
> Я хотел именно текстовый формат.
В вышеприведённой теме на гитхабе в одном из комментов предлагают временную меру обхода: делать файлам своё расширение, например mygamesavedata. Тогда встроенный в четвёрку сырой парсер жсона не подключится и не похерит.
Честно говоря, я сам был в шоке увидев это, я сделал тестовый проект, и действительно - годот лезет в файлы .json и херит их. Это возмутительно. Это нарушает вообще все границы допустимого. Я не открывал свои файлы, а они поменялись, неважно что туда дописалось, я ожидал что вообще ничего не допишется, что никто не полезет в мои файлы, пока я не разрешу. Пусть пишет метаданные себе в папку .import чо за хрень вообще?
>сериализации
Сериализация - из объектов в файл на диске (или поток байтов).
Десериализация - из файлов на диске (потока байтов) в объекты.
>плохо если нет инструментов для xml
Из коробки есть XMLParser, но это для десериализации:
https://docs.godotengine.org/en/stable/classes/class_xmlparser.html
Также есть какой-то аддон, но он уже 9 месяцев не обновлялся:
https://github.com/elenakrittik/GodotXML
Скажи, почему XML? Я слышал, он очень тяжёлый и неудобный.
>>1068169
Godot ничего не прячет. У каждого ресурса есть свойство resource_path, где указан UID:
https://docs.godotengine.org/en/stable/classes/class_resource.html#class-resource-property-resource-path
По умолчанию это свойство в свёрнутом блоке в инспекторе, но его легко посмотреть и сравнить.
Попробуй бету Godot 4.6 - там благодаря новой кнопке реально легче стало с ресурсами обращаться.
>язык уже прибит сам к себе по-дизайну
Иногда делают новые мажорные версии ЯП, не работающие со старым кодом. Как Python 2 и 3.
>>1068170
>что никто не полезет в мои файлы, пока я не разрешу
Я тебе больше скажу: Godot уже сколько-то лет перезаписывает tres-ресурсы... даже если они ни на байт не поменялись. Просто потому что Godot загрузил этот ресурс в память и ты потом решил что-то сохранить. Я не уверен, почему так, но, кажется, это из-за того, что раньше что-то там не сохранялось после изменений, и решили сохранять вообще всё открытое - на всякий случай. Если ты пользуешься гитом, то гит сравнивает хэш-сумму файла, видит, что она не поменялась, и не трогает файл; но при этом дата последней записи такого файла меняется на новую. Я заметил это, когда делал частичные бэкапы по дате изменения в WinRAR. Короче, с гитом это не проблема, но с архиватором на основе даты модификации получается такая проблема... И ещё это может замедлять время первого сохранения, если у тебя в проекте огромное количество ресурсов используется.
>>1068172
Мне никогда не приходилось делать такое за несколько лет пользования Godot... Я вообще этот root не трогаю.
>Скажи, почему XML? Я слышал, он очень тяжёлый и неудобный.
Вкусовщина, сейчас в плане (де)сериализации разницы никакой. Тем более json де-факто стандарт везде. Но в случае с вышеописанной проблемой, в xml все типы всегда представлены строкой. Что как бы говорит о универсальности сериализации (обычно все приводится к toString и почти не надо преобразовывать).
>Я вообще этот root не трогаю.
Правильно делаешь, я вот с юности трогаю root и никак не могу от этой привычки избавится.
>_enter_tree, но до _ready. Так что спуск вниз легко организовать самому.
1) Он происходит до _ready и главное что до @onready - что уже абсурд.
2) Для первого старта ты не можешь ничего делать, потому что у детей вообще никаких вызовов еще не было.
3) Он дергается каждый раз, как нода в сцену попадает что не дает возможности поменять местами с _ready. Эта штука практически бесполезна (нужна для другого), потому что до _ready.
В общем, это лютейший говнокод.
У тебя есть разовый _ready и многоразовый _enter_tree, в котором ты можешь настраивать новые состояния в момент входа, но ты не можешь это сделать во время старта. Чувствуешь абсурд?
Предвкушу ответ. Я описываю случай _enter_tree вместе _ready и @onready. В теории если выкинуть ready и использовать только _enter_tree - да можно использовать так (квази конструктор). Только вот уже проще вообще код отвязать от нод и сделать человеческий DI. Но тогда и простата редактора улетучивается.
(для гига проекта, в большой команде, возможно имеет смысл)
>В теории если выкинуть ready и использовать только _enter_tre
Кстати нельзя (только инициализацию).
Это старое. У них там новое недавно вышло / выходит.
Хочу чтобы мою игру однажды так спиратили. Маркер успеха.
Речь шла о совсем другом, не об _enter_tree.
Ещё раз посмотри на данную схему: >>1068148
Вот код, чтобы создать третью часть той схемы:
>var first_process: bool = true
>func process(delta: float) -> void:
>_ if first_process:
>_ _ first_process = false
>_ _ print("%s first process" % name)
А теперь внимание: когда ты запускаешь игру, данный участок кода может быть выполнен только после всех _ready, и он будет выполняться сверху вниз по дереву. Другими словами, где бы ты в дереве не находился, конкретно _process не может быть выполнен раньше готовности всех остальных нод, включая предков.
Если _process тебе в ноде не нужен, то можно так:
>func process(delta: float) -> void:
>_ set_process(false)
>_ print("%s first and only process" % name)
Тогда этот обработчик будет вызван единожды.
Да, выглядит как костыль, но главное, что работает... Вопрос в том, зачем тебе этот костыль? Ты тут уже не первый тред жалуешься, что тебе нужен start из Unity, однако, ты так и не смог внятно объяснить, в чём практический смысл стартовать без своих потомков.
Ещё раз, если ты пропустил: ноды-потомки - это твои жизненноважные органы, как сердце и т.п. Когда ты начинаешь жить, сначала формируется сердце - оно готовится качать кровь, и только потом ты учишься двигаться с поддержкой этого сердца. Ты же хочешь нарушить нормальный порядок: хочешь родиться с неподготовленным сердцем, научиться ходить и подключить к сердцу артерии. Это нелогично.
Если тебе очень-очень важно dependency injection из предков в потомки, тогда у тебя обычно два выбора:
1. Проверять, что у тебя есть твоя dependency:
>var navigator: Navigator # по умолчанию null
>func _process(delta: float) -> void:
>_ if not navigator: return # это null? -> выходим
Тогда твой код не обратится к null. Этот способ будет наиболее полезен, когда твоя dependency способна внезапно исчезать и появляться вновь по ходу игры (например, когда Player переходит между сценами).
2. Готовить своих потомков ДО входа в сцену:
>@export var player_scene: PackedScene # пример¹
>var player: Player
>var navigator := $Navigator as Navigator
>func start_game() -> void:
>_ player = player_scene.instantiate() as Player
>_ player.navigator = navigator # DI перед ready
>_ add_child(player) # тут сработает player.ready
Тогда твой Player будет ready лишь когда ты хочешь. Универсальный способ, который тебе нужно освоить, поскольку он применяется очень часто в коде Godot.
Откуда вызывать start_game(), спросишь? Легко:
>func _on_new_game_button_pressed() -> void:
>_ start_game()
Или что-то такое. Тебе не нужен Player до этого - ты подгружаешь и создаёшь Player только в начале игры, соответственно, ему нет нужды быть ready раньше (в главном меню игры, на загрузочном экране и т.д.).
Понимаешь, это - подход Godot. "Всё - сцена", сцены готовятся снизу вверх, от меньших - к большим, и их комбинирование в реальном времени - нормально. Постарайся это усвоить и тебе станет намного легче - избавишься от лишних ожиданий постронних ready.
________________
¹Подключение внешних сцен можно делать иначе:
>@export_file var player_scene: String # тут будет uid://
>var player := load(player_scene).instantiate() as Player
Или встроить ссылку прямо в код, например:
Абсолютный путь от корневой папки проекта:
>const PLAYER_SCENE := preload("res://player.tscn")
Относительный путь от папки с этим скриптом:
>const PLAYER_SCENE := preload("player.tscn")
Уникальный ID (ПКМ по файлу -> "Copy UID"):
>const PLAYER_SCENE := preload("uid://...")
Можно просто кинуть файл мышкой в окно с кодом.
preload() загружает файл в момент парсинга скрипта.
load() загружает файл в момент выполнения строчки.
Для тяжёлых файлов/цепочек файлов юзайте это:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
Оно позволяет сделать прогресс-бар на экране.
Код "@export ... PackedScene" ведёт себя как preload().
Цикличные preload() вроде бы не поддерживаются.
>Вот код, чтобы создать третью часть той схемы:
Это костыли и вообще крайне не хочется срать в _process, особенно когда его нет (и я надеюсь годот это оптимизирует и не дергает отсутствующий процесс скрипта).
>Вопрос в том, зачем тебе этот костыль? Ты тут уже не первый тред жалуешься, что тебе нужен start из Unity, однако, ты так и не смог внятно объяснить, в чём практический смысл стартовать без своих потомков.
Нужно "настраиваться" в ребенке. Единственный правильный вариант сейчас это в родителе дернуть метод "псевдо-конструктора" типа такого:
func _ready():
$Child1Script.enter(a, b, c) // не только инжект, что-то можем предварительно вычислять
$Child2Script.enter()
$ChildScene1.enter(c, d)
Это нормальный подход, пока не начинается безумие из сабсцен сабсцен.
Тут сразу в голову приходит - либо писать инжектор и полностью строит слой абстракции над годотом, или "в жопу, хочу сервис локатор" и настраиваться в ребенке.
Тогда в ребенке я бы просто
func _ready()
pass
func _enter(): // Start() - Unity
a = locator['a']
b = locator['b']
d = a.calculate(something)
Более того, я хочу чтобы он дергался каждый раз как попадает в дерево.
В общем, мне нужен нормальным "конструктор" перед кадром.
>не дергает отсутствующий процесс скрипта
Не дёргает, если одно из:
- в коде скрипта нет метода _process;
- где-то вызван set_process(false) ноды;
- дерево и/или эта нода на паузе;
- нода находится вне дерева.
>Нужно "настраиваться" в ребенке.
Это-то понятно... Непонятно - зачем тебе это?
Ты изобретаешь какой-то велосипед. Ещё раз:
1. Берёшь файл сцены с диска (любым способом).
2. Делаешь инстанс сцены (экземпляр объекта).
3. Настраиваешь эту сцену как тебе угодно.
4. Вставляешь эту сцену в дерево сцены.
5. У сцены происходит _ready и прочее.
Твоя проблема в том, что ты путаешь порядок, ты:
1. Берёшь файл, создаёшь инстанс.
2. Вставляешь его в дерево сцены.
3. У него срабатывает _ready и т.д.
4. И тут ты хочешь его настроить...
Повторяю в который раз: так делать - неправильно.
>пока не начинается безумие из сабсцен сабсцен
Что это значит? Ты не понимаешь инкапсуляцию?
1. Родитель создаёт ребёнка и настраивает его.
2. Ребёнок добавляется родителем в дерево.
3. Ребёнок создаёт внука и настраивает его.
4. Внук добавляется ребёнком в дерево.
5. Внук создаёт правнука...
И т.д. Что тут сложного?
Ну, в моём коде проблем с этим не было...
>3. Настраиваешь эту сцену как тебе угодно.
Так хочется унификации между настройкой ноды из файла и ноды которая в редакторе прикреплена.
Если бы _enter_tree был бы после _ready - проблем бы не было.
>Повторяю в который раз: так делать - неправильно.
Почему? Во первых у тебя полный контроль над порядком,
$Child1.enter(a, b)
$Child3.enter()
$Child2.enter($Child3.getLeftHand())
Во вторых ты вызываешь из родителя, тут все норм.
Если забудешь вызывать "конструктор enter" все свалиться сразу с NPE.
Ты можешь перегрузить состояния вызвав снова enter(...)
>>1068231
>>пока не начинается безумие из сабсцен сабсцен
>Что это значит? Ты не понимаешь инкапсуляцию?
Ты в сцену передаешь a, b, c - это твои зависимости модуля.
А потом ты прикручиваешь сабсцену у которой зависимость d, e
А у нее тоже есть сабсцены зависимостью x,y,z
В итоге мне руками продеться просунуть a, b, c, d, e, x, y, z, хотя мой модуль зависел только от a, b, c.
В такие моменты захочется для сабсцен либо авто инжектор (IoC) или локатор (но у нас нет Start()).
В нормальном мире разработки, мы спускаемся сверху вниз, поэтому локатор всегда собран для детей, тут же адовая херня, чтобы оправдать идею нод (из-за этого _enter_tree вообще бесполезен)
>>1068231
Я думаю мы всех зае...
>хочется унификации
Ясно, ты ищешь золотой молоток...
Геймдев - это ad hoc на ad hoc и ad hoc погоняет.
>ноды которая в редакторе прикреплена
Ты всю игру целиком в редакторе собираешь?
Смотри, какой порядок должен быть, примерно:
0. Windows/Linux загружает Godot.exe в RAM.
1. Godot открывает main scene - "bootstrapper.tscn".
2. В бутстраппере есть только лого, прогрессбар и загрузочный код, который загружает "game.tscn" и переключает "сцену" на только что загруженную.
3. Сцена-игра имеет главное меню, настройки и т.п. Ожидается ввод пользователя для начала игры.
Дальше зависит от типа игры, но, например:
4. Сцена-игра загружает "world.tscn" или "level.tscn".
5. Мир грузит/уровень получает "игрока" и текущие декорации, загружает менеджер мобов и т.п.
6. Менеджеры спавнят свои сущности и т.д.
Если ты делаешь что-то типа стратегии, то у тебя специальный менеджер юнитов, который грузится в процессе начала новой/загрузки сохранённой игры. Конкретный спавн юнитов - детали имплементации (наверное, вообще придётся отказаться от дерева с нодами, чтобы использовать Servers напрямую - так рекомендовали делать во времена Godot 3.x).
Короче, суть в том, что это всё ad hoc системы. Нет универсального автоматического решения, и дерево, присутствующее в Godot, полезно только для мелких проблем в мелких играх и GUI, в остальном не нужно.
Ну а для прототипов игры вообще забей на все эти особенности - отрефакторишь потом. Главное тут не размножать глобальные сущности без надобности - усложняют рефакторинг в будущем, а вот насрать локально - это всегда пожалуйста, главное чтобы наваленное не протекало в соседние ветки дерева.
> наверное, вообще придётся отказаться от дерева с нодами, чтобы использовать Servers напрямую - так рекомендовали делать во времена Godot 3.x
Ну например этими юнитами может быть одна мультимеш-нода, которая добавляет/удаляет инстансы мультимеша при необходимости, а так же обрабатывает коллизии всех инстансов, рассматривая их как точки одного общего коллижен-шейпа.
Мне с дивана кажется это нехилой такой оптимизацией.
А, и ещё вот пример разработки снизу вверх:
1. Делаешь визуальную сцену юнита, которая может реагировать на команду "включить анимацию X".
2. Делаешь сцену-тело юнита, которое может тупо перемещаться по прямой, поворачиваться и т.д. по получаемым снаружи (сверху) командам и имеет в потомках визуальную сцену, которой командует.
3. Делаешь сцену-контроллер юнита, который умеет перемещать юнит по заданному маршруту... Здесь, наверное, лучше сразу заложить "группу юнитов"... Контроллер получает path типа Array[Vector2] извне.
4. Делаешь навигатор типа Resource, что ищет путь, проходящий из A в B, сообщает о непроходимости.
5. Делаешь контроллеры войска: ИИ и игрока. Оба руководят своими юнитами, отправляя им path, что получили из навигатора. Юнитов создают сами. Их основное отличие: ИИ оценивает ситуацию на поле.
6. Делаешь мир-карту, которая делает навигатор и обновляет его состояние при своих изменениях.
7. Делаешь менеджер игры, который:
- имеет мир-карту и контроллеры войск;
- передаёт контроллерам навигатор карты;
- передаёт ИИ-контроллеру состояние игры;
- следит за статусом игры, меню и т.д.
Здесь только в одном месте DI - в контроллерах, управляющих войсками, которым нужно знать, где возможно разместить юниты и куда их отправлять.
При этом многие детали можно тестировать, т.к. зависимости создаются сверху вниз, а не наоборот. Контроллер войска ничего не сделает без своего навигатора, но контроллер юнита может получать очередной маршрут от любого другого источника.
Т.е. зависимости не протекают слишком глубоко.
И уот так уот мы можем детать любые Godot-игры.
А, и порядок "активации" (ready) сцен:
1. Визуальная сцена юнита - ей ничего не надо.
2. Сцена-тело юнита - тоже не надо - всё своё.
3. Сцена-контроллер юнита - аналогично.
4. Карте мира ничего не надо.
5. Навигатор создаётся картой.
6. Менеджер игры создаёт контроллеры войск.
И никакого "ожидания root.ready" нигде не нужно.
>>1068294
>мультимеш
Он только для плотных однородных групп подходит.
>коллижен-шейпа
Там, в стратегиях, лучшая коллизия - это Rect2, лол.
Да. В 3D RTS тоже используют Rect2. Где-то уже был длиннющий отчёт такой 3D RTS со всеми нюансами оптимизации, где они сидели с профайлером и подсчитывали миллисекунды разных коллизий. В результате сделали коллизии на Rect2, чтобы было максимально быстрое выделение юнитов мышкой.
>>1068300
Я люблю аниме, но это как-то стрёмно выглядит...
Для какой игры тебе такой мутант потребовался?
>Для какой игры тебе такой мутант потребовался?
Хочу сделать девочку курьера которая на самокате по городу катается.
А зачем ты нам её сиськи и жопу показываешь? Я думал ты хочешь сделать ВНку про бордель.
>курьера которая на самокате по городу катается
Т.е. ты сгенерировал на 90% больше достаточного и на 99% меньше требуемого для игры. Понятно.
>>1068304
Не надо быковать на новичка...
>>1068308
>А зачем ты нам её сиськи и жопу показываешь?
А что такого? Ты нофапер в терминальной стадии?
>Ты всю игру целиком в редакторе собираешь?
Ну как бы воркфлоу подразумевает, что сцена будет собрана в редакторе и дальше по своей природе будет либо прибита к чему-то, либо подгружаться.
>наверное, вообще придётся отказаться от дерева с нодами,
Тоже пришел к такому выводу, для многолетнего проекта.
Пока на прототипах я решил говнокодить, у меня тут синдром утенка мне трудно писать такой код, поэтому серьезно ломает и ною. Но я уже стал привыкать. Если сначала я делал модули и перемещал что-то между проектами (не особо много), то сейчас тупо копирую целиком проект и чищу лишнее вилкой, потому что смешалось все - люди, кони
>Если ты делаешь что-то типа стратегии,
В данный момент отошел от идеи игры, кусками делаю/повторяю/экспериментирую над мини механиками без цели реализовать что-то (учусь/тыкаю, засматриваюсь на блендер).
>Смотри, какой порядок должен быть, примерно:
Так примерно и представлял, но спасибо за бэст практис.
>Servers
Это интересно.
Не, скорее такой, с сидушкой.
Сделай так, чтоб голова сильно болталась:
https://en.wikipedia.org/wiki/Bobblehead
Должно будет забавно выглядеть.
>>1068319
>>Servers
>Это интересно.
Тогда читай документацию:
https://docs.godotengine.org/en/stable/tutorials/performance/using_servers.html
>делаю/повторяю/экспериментирую над мини механиками без цели реализовать что-то (учусь/тыкаю, засматриваюсь на блендер).
Молодец, продолжай. Блендера не бойся.
Го смотреть видосик вместе со мной. А потом за работу!
Вот тут выдумали тулчейн для создания игор в блендере с прикрученным туда годотом вместо BGE, просто бурлеск!
https://www.youtube.com/watch?v=YW5N8ANrm9c
Какие существуют юзкейсы, когда однозначно C# -> GDScript? Правильно ли я понимаю, что если в моей игре не будет никаких особенно трудоемких вычислений вроде pathfinding'а сотен энтитей каждый тик, то используя GDScript, я ничего не потеряю? Насколько глубоко в движок уходят их АПИ, нет ли такого, что на C# можно ковырять движок более глубоко, чем на GDScript?
Закончил вышку (бакалавриат) на программиста, начал работать и понял, что программирование по сути своей - это очень скучно. Всегда хотел работать в геймдеве, но мне ближе работа на уровне геймплейного программиста, чем программиста систем или движка. Короче говоря, кодинг - средство достижения цели, которое в процессе не доставляет радости. Сейчас параллельно обучаюсь на 3D дженералиста и буду менять профессию. Потерял в ВУЗе 4 года, вот теперь думаю чо делать, такие дела. Спасибо тем кто ответит, попутного ветра в ваших проектах.
>У меня пока никакого бекграунда с Годотом, предыдущие треды я тоже не читал
Ну без чтения всех предыдущих тредов тебе тут делать нечего.
Бери ГДСкрипт как нормальный человек и не еби мозг. Если числодробилку писать, то все равно на плюсах. Шарп это чисто для перекатчиков сам-знаешь-откуда, которые всего один язык за свою жизнь осилили.
>Если числодробилку писать, то все равно на плюсах
Так то аргумент, конечно.
>Шарп это чисто для перекатчиков сам-знаешь-откуда
Но все-таки - АПИ идентичны? Нет такого, что C# имеет больше возможностей при работе с движком в сравнении с GDScript?
>>1068330
>Не теряй время на годот, это для энтузиастов, денег тут нет.
Так можно сказать про геймдев в целом. Я склонен называть себя энтузиастом, потому что готов этим заниматься, даже не получая денег. Мне это интересно. Параллельно сейчас осваиваю 3D, надеюсь, что смогу прокормить себя с него. Там сейчас тоже все очень плохо, но всегда есть более технические позиции на предприятиях, о которых многие забывают. Энивей, я хочу связать либо с играми, либо с 3D свою жизнь, так что буду искать пути.
>когда однозначно C#
Когда ты готов хуи сосать за возможность писать на любимом с#. Шарп как был недопилиным говном, так и остался. Бессмысленный рудемент для фанатиков который начнет глючить после первой тысячи строчек когда ломая запуск, отладку, тестирование вечно нерешенной проблемой.
В вебе гдскрипт лучше, в остальном одинаково, все. Теперь бери и начинай ебашить вместо бесконечных разборок "а что же лучше". Лучше - ебашить.
Соглашусь полностью. Я Шарпист в продуктовой разработке и сколько не пытался его юзать с Годотом, это всегда какой-то пиздец. Постоянно нужно всё рекомпилить, а уж если ты делаешь эдитор плагин, это вообще пиздец. Ассембли пересобирать приходится, потому что там ебанина с обновлением стейтов, в целом весь воркфлоу довольно ебаный и держится на соплях. Они даже в 4.5 и предстоящем 4.6 например, не сделали нормальную связь сигналов с кодом через эдитор. Стейты не обновляются тобишь. Хукай через код, а потом смотри в редактор и ахуевай, вспоминая что у тебя там и как. Просто непонятно зачем нужен весь этот пердолинг когда есть гдскрипт, на который я успешно переехал и в ус не дую
Прежде всего, лучше всего - читать официальную документацию:
https://docs.godotengine.org/en/latest/tutorials/scripting/gdscript/index.html
https://docs.godotengine.org/en/latest/tutorials/scripting/c_sharp/index.html
Про разницу между API языков вот тут много чего-то написали, я не читал пока:
https://docs.godotengine.org/en/latest/tutorials/scripting/c_sharp/c_sharp_differences.html
GDScript создан специально для Godot и поэтому он тупо удобнее как "язык-клей", язык игровых сценариев. У него наиболее полная и удобная поддержка API Godot, т.к. API Godot создаётся под GDScript и все потроха Godot построены с учётом GDScript. Кроме того, GDScript будет гарантированно работать без проблем на любой платформе, где может работать Godot. На GDScript абсолютное большинство туториалов из сторонних источников, абсолютное большинство разработчиков, готовых помочь советом. Его легко освоить и новичку, и бывалым кодерам. Также его не нужно компилировать, поэтому легко работать в режиме "написал строчку - запустил - написал вторую", и есть hot reloading (но он не всегда работает так, как ты этого ожидаешь). Крайне удобно писать свои собственные "tool-скрипты" (инструменты) для расширения функциональности редактора без перезапуска самого редактора. Мелкие скрипты можно встраивать непосредственно в файлы сцен или даже файлы ресурсов, а также подгружать в рантайме из сторонних файлов или даже окна пользовательского ввода - можно сделать "игру для программистов" прям из коробки. Так что это выбор по умолчанию для любой Godot-игры.
Главный недостаток GDScript - это если тебе нужен цикл for/while на несколько десятков или сотен тысяч итераций за один кадр (1/60 секунды - один стандартный вызов _physics_process) - тут он, конечно, будет медленным, но не настолько медленным, как может показаться - для многих прикладных задач производительности GDScript хватает, и он, по моим ощущениям, быстрее популярных "скриптовых" языков (Python, JavaScript в браузере и т.д.). Лично я в качестве эксперимента делаю нейросеть чисто на GDScript и у меня получалось симулировать что-то вроде нескольких десятков тысяч "нейронов" с приемлемой частотой (около 30 тиков в секунду). Также я много генерировал процедурных карт на GDScript с помощью клеточных автоматов и это было, на мой взгляд, приемлемо. И всё это - на процессоре 2007 года, в однопоточном режиме, 3 ГГц. Так что производительность GDScript не так сильно давит, чтобы с него слезать в 99.99% случаев. Другие недостатки некритичны и будут в будущем исправлены (например, скоро обещают систему traits, которая должна компенсировать отсутствие множественной наследственности, но множественная наследовательность не так уж и нужна, когда ты чаще всего пользуешься композицией и агрегацией сцен-объектов).
У C# преимущество в производительности на уровне "всего лишь в 2-5 раз медленнее C++" и более лёгком доступе к "серьёзным" кодовым библиотекам, например, к библиотекам машинного обучения (их можно прикрутить к GDScript, но, я думаю, специалистам машоба будет легче воспользоваться C# или Python, чем GDScript). В остальном его использование вместе с Godot оставляет желать лучшего по сравнению с GDScript - но я говорю это как человек, который несколько лет назад кринжанул с API Unity на C# и сломал все пальцы ненавистными {скобачками}, поэтому, возможно, тебе будет норм. Кроме того, есть какие-то проблемы с платформами типа веба и мобилок, но я не уточнял. А, и ещё он должен компилироваться, так что не вариант использовать в классическом скриптовом режиме (строчка - запуск - строчка - запуск). Сам я планирую пощупать C# в Godot для попытки ускорить свою симуляцию нейронки, но это весьма и весьма специфичный юзкейс.
Также возможно программировать в Godot с использованием C++ и многих других языков, но это всё будет сложнее. Поэтому рекомендую начать использовать Godot с GDScript и уже потом думать, нужно ли тебе что-то кроме GDScript. В общем и целом стратегия такая: пишешь свой говнокод на GDScript, играешь в прототип, и если чувствуешь, что алгоритм правильный и очень нужный, но слишком медленный, то переписываешь его на другой язык (C#, C++ и т.п.). Если всё норм, оставляешь как есть. Если идея оказалась говном - то просто удаляешь скрипт и забываешь его, сэкономив время, т.к. написал его очень быстро.
Раньше (во времена Godot 3.x) был визуальный язык с блоками и ниточками типа blueprints в UE, но им почти никто не пользовался, его считали недоделанным и неудобным, и в итоге вырезали. Что-то подобное ему можно использовать для написания шейдеров - но лично мне не понравилось и я быстро начал изучать API для обычных текстовых шейдеров. Не стоит бояться шейдерного языка, там главная головная боль - это преобразование векторов матрицами, что никак не зависит от конкретного языка (т.к. ты сам должен в голове представлять, что на что тебе нужно умножать).
На мой взгляд, программирование - это весело, но только когда ты можешь глазами увидеть и руками пощупать свои результаты работы. Поэтому рекомендую начать сначала с простых аркадных 2D игр или чего-то связанного с GUI. В большинстве 3D игр используются те же алгоритмы, что и в 2D играх, но для 3D игр ассеты намного сложнее делать (в смысле, если сравнивать "лоуполи модель из Blender" со спрайтом, нарисованным в Microsoft Paint мышкой).
>>1068341
Если так сильно трясёшься за свой скриптовый говнокод, в котором чёрт ногу сломит - Godot позволяет зашифровать игру, сделав кастомную сборку движка с ключом расшифровки... ну, ты понял, ключ под ковриком перед дверью, чтобы игрок мог запустить зашифрованную игру и поиграть. Но от декомпиляции C# тебя в любом случае не защитит, и даже по C++ можно пройтись дизассемблером и раскрыть все твои грязные секретики, которые ты нечаянно скопипастил как String-константы.
А в остальном - хоть в опенсурс бесплатно свой игрошедевр выкладывай, в 99.9999% случаев его поленятся даже скачивать. Не зря ведь стримеры денег требуют с геймдевов, чтобы играть в их поделки на стримах - т.е. мало сделать хорошую игру, нужно ещё заплатить людям, чтобы в неё хоть раз поиграли (стиснув зубы и стараясь не наброситься на тебя в бешенстве).
Да, геймдев - это дорогое хобби для развлечения или неблагодарная работа для неопытных людей с горящими от игр глазами.
>пиздаболище на самоподдуве
Чекай пикрил, умница. Ты правда думаешь, что во вселенной существует 1 (один) человек, недовольный стейтом Шарпа в Годоте? Не, ну правда что ли?
>Ну или ты опять пиздаболишь
Зачем утруждаешь себя отвечать на посты семёна-пиздабола? Ну вот цель твоего ответа в чём, что донести хотел?
По факту это давно существующие проблемы, там с вагон и маленькую тележку наберется. Кому не похуй могут проверить пулл реквесты, ишью на гитхабе годота и их коммьюнити ресурсы. Шарп работает как говно, и я тут не злорадствую, а печалюсь, это мой основной язык
Я не говорю про наличие или отсутствие каких-то методов или свойств. Под "полнотой" я имел в виду, например, тот срач из-за рейкастинга, когда рейкаст возвращает Dictionary - и это абсолютно нормально в GDScript, но вызывает дикую тряску у сишарперов с их сборщиком мусора. Более того, насколько я понимаю, объекты Godot вообще нельзя высвобождать на стороне своего языка (иначе будет ошибка доступа к памяти?)... или наборот, нужно подчищать за Godot?.. тогда как в GDScript с этим всё просто и понятно. Т.е. да, ты можешь использовать API Godot снаружи, но оно накладывает лишний слой нервотрёпки по сравнению с GDScript - и это я считаю "неполной" реализацией API. Она была бы полной, если бы всё было 1-в-1 как на GDScript (включая пользовательский опыт разработчика, т.е. что можно и нельзя делать с объектами, как они влияют на память и GC и т.д.), но это пока не так (ждём Godot 5?).
>>1068346
У него синдром утёнка. Когда какой-то язык/инструмент - твоя первая любовь, то начинаешь беситься с любой критики...
Алсо, не всё API, доступное в GDScript, доступно в C# (и других языках), например:
>preload, as it works in GDScript, is not available in C#. Use GD.Load or ResourceLoader.Load instead.
И это написано в официальной документации, на которую я дал ссылку выше (пришлось читать):
https://docs.godotengine.org/en/latest/tutorials/scripting/c_sharp/c_sharp_differences.html
Ещё, из заметного сразу, в C# отсутствует onready:
>GDScript has the ability to defer the initialization of a member variable until the ready function is called with @onready.
>However C# does not have this ability. To achieve the same effect you need to do this...
Т.е. отличия в API всё-таки есть, и не в пользу удобства C#.
Там ещё в таблицах куча функций помечена как "N/A", что подразумевает отсутствие со стороны C#, как я понял.
>Моя первая любовь это паскаль.
Моя тоже. И я ненавижу все языки с {операторными скобками}, особенно C/C++/C#. Нет ничего хуже {скобок}...
>почувствовать вкус настоящей свободы, где я могу практически всё
Вообще-то, любой полный по Тьюрингу язык даёт тебе "вкус настоящей свободы", включая, если очень сильно хочется, написание своей собственной операционной системы начиная с бутлоадера - напиши только компилятор в ассемблер. Так что тут ты конкретно обосрался, сравнивая багофичи и/или синтаксический сахар языка высокого уровня со свободой. Как раз наоборот - всё, что ты перечислил, создано для того, чтобы существенно ограничить твои возможности, или на ограниченное время обойти наложенные ранее ограничения (т.е. опасный костыль, который обязательно выстрелит тебе в ногу в будущем). Если бы ты хотел реальной свободы, то писал бы на чистом C без плюсов или на Паскале без объектов (там тот же доступ к памяти, что и у C, плюс доступны ассемблерные вставки, когда хочется извращений), а не вот этой вот мерзкой Java-подобной подделке от Microsoft для Microsoft, которую кто-то "случайно" притащил в геймдев (очевидно же, что Microsoft специально подкупили несколько игровых движков, чтобы подсадить наивных ньюфагов на свою иглу).
Короче, плох тот программист, что полагается на "возможности" высокоуровневого языка и не может реализовать свою "свободную" программу с использованием базовых элементов любого языка программирования, а именно: переменные, математические и логические операторы, условия, циклы и процедуры или функции. Даже не так - перечисленные элементы избыточны для реального программиста, потому что ему было бы достаточно 1 команды ассемблера для разработки программы абсолютно любой сложности. Настоящие программисты создают свой собственный компьютер внутри игры "Жизнь" Конвея, Minecraft, Factorio и других полных по Тьюрингу систем. Вот в чём реальная свобода.
Настоящий программист сможет симулировать всю Вселенную с помощью кучки камней на песке. А ты?
Первое правило. Бери родной язык системы, что бы тебе не говорили
андроид - котлин (не js нейтив или дарт)
айфон - свифт (а не котлин или дарт или жс)
годот - gdscript - она максимально близок и удобнее для вката. Потом уже сам протестируешь и решишь что надо, хоть на раст переходи (это шутка, все знают что будущее за zig).
Смирись с тем что придется писать на десятке языков. Оставь дотнет для игрового сервера. Это хорошая технология.
И вообще старайся без фанатизма смотреть на языки - это лишь инструмент, а не религия (и возможно для твоей задачи игрового бэкенда будет удобнее какой-то голанг или js или даже питон, потому что привык к gdscript).
То есть, ты выбираешь гдскрипт не потому, что челик запостил картинки со статистикой, а потому что это инструмент без "шероховатостей" для годота.
И только с опытом в техе ты уже можешь страдать всякой фигней - вплоть до кода на С++
>Но кому не похуй? Не нужно тешить свое эго что кто-то будет пиздить твой проект. А если это происходит то ты уже добился успеха
Пока ты публикуешь демки на дваче, кто-то слямзит, заменит картинки и опубликует в стим.
>А в остальном - хоть в опенсурс бесплатно свой игрошедевр выкладывай, в 99.9999% случаев его поленятся даже скачивать.
Не стоит исключать что ты креативный гений и есть шанс сделать свой майнкрафт (0,000001%) есть талантливые люди, которые могут передавать погружение просто на базе своей интуиции, даже не осознавая это и пока ты будешь пукать в стульчик борясь с прокрастинацией, кто-то твой билд релизнет в itch стиме (и пиратом станешь ты).
Но на самом деле больше шанс что украдут идею, кто будет в твоем говнокоде разбираться.
>Моя тоже. И я ненавижу все языки с {операторными скобками}, особенно C/C++/C#. Нет ничего хуже {скобок}...
Чел ты тоже ставишь ":" в норм редакторе ты нажимаешь "{" у тебя тут же появляется вторая "}" и дальше ты нажимаешь энтер и все позиционируется как надо.
Тоже самое, только еще форматирование работает. Даже мейнтейнеры питона на конференции говорили, что отступы это вероятно была ошибка.
>>1068380
ПРО-программисты часто используют связки языков, типа
С++ и lua
С и python
etc...
Тут у тебя на вооружение может быть С++ и GDScript. Вероятно числодробилки с контролем аллокации и прочие узкие места тебе захочется делать именно на С++. Но это будет еще не скоро, просто знай что возможность есть.
Странное решение. Типа ты уже используешь годот - ну типа используй для кода и так. Лучше бы какую-то максимальную совместимость сделали, чтобы без экспортов по одному только ctrl+s все работало сразу в годоте как со спрайтами :3
> чтобы без экспортов по одному только ctrl+s все работало сразу в годоте
Это ещё при трёшке было. Шапку читаем.
https://github.com/V-Sekai/godot-blender
Потом правда, по очевидным причинам проект заглох.
Если очевидное не очевидно, то ответ под спойлером: бленд-файл это рабочий каркас с кучей "строительных лесов" из которого следует экспортировать только малую часть готового финишного меша.
Не несите эти "туториалы" от школ, если сами не повторяли их, они делают "слонов" (специальные косяки). Такой спринг арм улетает в пол чтобы посмотревшие "тутор" карлики пошли на их сайт разбираться почему у них не выходит.
> они делают "слонов" (специальные косяки)
Все делают. Не бомби, ньюфажек. Слоны - это база айти.
> делают "слонов" (специальные косяки)
Впервые слышу это выражение. Какой смысл, если люди тупо дропнут и пойдут дальше? Проще на сайт затянуть ассетами. Видел видос, чел довольно грамотно знакомил с годотом, но при этом сделал платные ассеты (причем чужие).
Почему так много скама у годот-видосов? Это не пассивная агрессия, просто когда отдыхаю, смотрю краем глаза на видосы других движков шлюха! и вроде они популярнее, но инфоцыганских заманух намного меньше. может просто низкокачественное улетело на дно?
Не хрюкай, сказал тебе уже.
>>1068420
Древнейший термин, со времён когда их вставляли преподаватели университетов в статьи по программированию объясняя алгоритм, но делая ошибки в коде, чтобы его не копировали тупо. Выражение "слона то я и не заметил" ты наверное слышал.
>Почему так много скама у годот-видосов
Да не много, ну кто-то говорит что код бусти. у кого то ассеты на бусти, а школы используют такой прикол, вроде и код показали, но не дали настройки камеры и про настройку спрингарма в видосе ничего нет, если посмотреть глазами и повторить - работать не будет.
> Не хрюкай, сказал тебе уже.
Ну ладно.
>>1068441
Шапка гласит: читай документацию - качай примеры. Мы не читаем шапку, а потом хрюкаем.
>>1066864 (OP)
ОП, переделывай шапку. Убирай свои быдляцкие сайтики-визитки. Туда всё равно никто не ходит.
>>1068395
>Шапку читаем.
>ОП, переделывай шапку
Единственная годнота это тот гигачад с вокселем и планетарными перелетами.
В awesome есть моменты, которые вообще было бы стыдно добавлять (ну тут не вина ОПа). Сайт с шейдерами не открывается (эти дебилы используют какой-то фильтр "плохих ip", параноики).
Думаю в мире годота куда больше интересных статей и материала чем ссылка на доку. Ну, как минимум это.
https://www.youtube.com/@GodotEngineOfficial/streams
По поводу пика, какое-то дилетантство, нафига высер со срача постить (кроме как самоутвердиться ОПу)? Есть дока, там обговариваются момент построения архитектуры и лучшие практики (в целом, годот очень гибкий, вплоть до того чтобы выкинуть ноды. Я искал разные подходы и видел что никакого не тыкали в определенные архитектуры, а наоборот помогали предлагая варианты).
Есть подозрение что ОП малолетний долб дарование и натаскал полезное только ему, а не для вкатывающегося анона.
Так что в шапку посылать смысла нет.
>Это ещё при трёшке было. Шапку читаем.
https://github.com/V-Sekai/godot-blender
Там без аддонов годот поддерживает блендер файлы, надо только путь до блендера указать (он спросит, как только файл закинешь)
Ну и на будущее "awesome" не переводят
awesome golang
awesome kotlin
awesome dotnet
Это специальный базворд (ставшим нарицательным), который позволяет сразу окунуться в различные реализации той или иной техи, пошло из программирования (вроде).
АРГУМЕНТЫ КОНЧИЛИСЬ @ ДОКОПАЙСЯ ДО СЛОВ
>>1068395 >>1068443 >>1068458
Лично мне пофиг на эту "шапку", на дваче эти "шапки" никогда ничего по-настоящему полезного не имеют, заполняются битыми ссылками прост чтоб было, и игнорируются анонами в треде, даже если в шапке модератор большие цветные буквы использует.
Единственное, что нужно для Godot - документация. Остальные туториалы - это сломанный телефон, они пересказывают с ошибками документацию Godot... Видосики вообще лучше не смотреть лишний раз, и стараться делать всё своими руками, осознанно.
На ОПа не быкуй лишний раз, он тут модератор или приближенный к модератору, так что спасибо ему, поддерживает этот тред в чистоте и порядке.
ОП вроде писал, что он пользуется Godot чисто по необходимости и всё ещё сидит на тройке. Пилит казуальное что-то для браузера и мобилок. Если игнорировать Godot-культистов и вкатунов, то ОП - эталон, среднестатистический пользователь Godot, выпустивший, как я понял, уже несколько Godot-игр.
мимо не ОП, но наблюдаю за ним несколько лет
>поддерживает этот тред в чистоте и порядке.
Буквально на днях веником снесли посты о годоте, потому что там в голове что-то щелкнуло.
Смысл поддерживать в чистоте, когда на доске 6 постов в час (да еще половина мои, лол). Ладно бы я понял, мол тут флудом ньюфагам мешаем, так тут вообще никого нет.
> ОП - эталон, среднестатистический пользователь Godo
Сам себя не похвалишь, никто не похвалит.
> ОП - эталон ... выпустивший, как я понял, уже несколько Godot-игр.
Что у вас за комплексы связанные с релизами игр? Даже отдельное ругательство есть - безыгорка. Представляю как в /pr бы кто-то кого-то оскорбил тем что он безпрограммка лол.
Безыгорка безопыта, плез, тебя читать только время тратить. Другое дело что ты дерейлишь ньюфагов в таких же безыгорок как сам, но что поделать, очередная ловушка ньюфагов.
>веником снесли посты о годоте
Была критика уровня "годот говно, пруфов не будет", которой место в движкосраче. Единственный пост, который случайно зацепило - про JSON, но там я сам виноват, нужно было сразу ссылку на github давать.
>Смысл поддерживать в чистоте
Чтобы не превращать раздел в филиал /b/реда.
>постов в час (да еще половина мои
Просто ты флудер. Качество важнее количества.
>комплексы связанные с релизами игр
>Представляю как в /pr бы кто-то кого-то
Если и сравнивать, то с /pa/ или /td/, где сидят творческие аноны и ПОКАЗЫВАЮТ свои поделки остальным анонам. Представь себе раздел про 3D моделирование или рисование, где никто никогда ничего графического не постит и только сочиняет весёлые истории о том, какой инструмент хуже. В разработке игр сложнее поделиться результатами действительности - ведь в игру нужно ИГРАТЬ, а не смотреть со стороны. Поэтому аноны /gd/ должны релизить игры и делиться ссылкой/ключами, а не зафлуживать раздел срачами про инструменты - повторяю, творческому разделу нужно творчество.
Программач - отдельная сфера, там сидят гребцы вёслами на галерах с зряплатой, а не творческие; программирование может быть искусством, но в конкретном случае /pr/ про РАБоту, а не искусство.
>Безыгорка
Сколько игр на itch или яндекс диске опубликовал?
Такие гигачелы с вокселями вносят вклад в комьюнити годота больше чем какая-то игра в стиме.
Чужая игра вообще не вносит ничего полезного. Это как гордится машиной соседа. В то время как ковыряние демки просто бесценно и заслуживает больше уважения чем чужой успех (про создание инструментов я вообще молчу). Особенно это забавно смотрится, когда успех современной игры на 99% зависит от залитого в него трафика (маркетинга).
Был же маркетолог который рассказывал:
100 - человек скажут говно
1.000.000 - человек скажут шедевр!
Ну я понимаю, что тут какая-то своя травма. Только для человека со стороны это никак не цепляет.
Хотите вносить вклад в развитие? Заливайте свои бесплатные демо игры так же и на гитхаб. Пускай люди ковыряются.
>Была критика уровня "годот говно, пруфов не будет", которой место в движкосраче
Не помню такого. Да кому не пофиг, ты думаешь кто-то эти треды перечитывает? Это больше чат чем "форум", причем чат с 6 постов час на всю доску.
Идеальный инструментов не существует, очень хорошая реакция людей из js и го сообщества. Мол, "да, не идеально и что?" И правда и что? При этом js невероятно гибкий, а в го асинхронность под капотом, без проблем покраса функций.
Годот не самый популярный движок, мне было правда интересно почему люди выбрали именно его, на это должна быть реальная причина.
>Чтобы не превращать раздел в филиал /b/реда.
Для этого надо постинг на два порядка больше.
>Просто ты флудер.
Есть такое, просто у меня было много свободного времени в декабре. Так что скоро станет чище :)
>и только сочиняет весёлые истории о том, какой инструмент хуже.
У тебя какая-то своя травма. Не бывает идеального инструмента. В целом люди довольно самостоятельные и сами решат работать с инструментом дальше или нет, никакая твоя чистка не поможет. Критически мыслящий человек сделает куда больше, чем человек флюгер, которого пост анона может ввести в сомнения. школота все равно выберет популярное, даже если сложнее вкатится
>Если и сравнивать, то с /pa/ или /td/, где сидят творческие аноны и ПОКАЗЫВАЮТ свои поделки остальным анонам
Толку мне от того что анон сделал? Ну опять же порадовались за машину соседа - офигеть достижение.
Если правда переживаешь за сообщество и будущее годот - публикуйся в github. Вот там лежат воксели или гта3 (вроде ручной порт) - это вообще бесценно если ты решишь писать нечто близкое. Обратный инжиниринг в опенсорсе - это вообще золотой кладезь знаний.
Чел который опубликовал адаптацию A2Star для гексов на гитхаб сэкономил мне много часов. Я вообще не знал с какой стороны подойти. Вот это я понимаю вклад, а не демонстрация "чужой машины".
AStar2D пальцы с утра не попадают
>tool-элементов
У меня крашило редактор, хз по чьей вине, будь осторожен и мой руки перед едой
Редактор не крашило пока, а от null object при дубликации и тд мне помогает if not is_inside_tree(): return в сеттерах-геттерах. Алсо я на тройке, в четверке наверняка все иначе.
>демонстрация "чужой машины"
То есть ты расписался в том, что игры для тебя - это просто средство заработка на тупых малолетках, а сам играть в игры ты не собираешься, ведь в игры играют только тупые малолетки. Правильно понял?
И вот такие кабанчики потом жалуются, что их игра заработала 5 рублей на яндекс.играх и была удалена за низкий рейтинг. Неблагодарные малолетки, да?
Играй в игры >>>>> делай игры >>>>> лей на гитхаб.
Нефига ты завернул. Даже боюсь представить ход твоих мыслей.
> это просто средство заработка на тупых малолетках,
У меня на последней идеи был такой жанр, где и так 1.5 человека в стиме играет, так я еще натянул свой бред, вместо общепринятой практики.
И я не утрирую, все гранд стратегии настолько похожи друг на друга, что они просто боятся что-то сломать, потеряв и так околонулевую аудиторию.
Endless legend 2 - авторы решили тупо скопировать первую часть, когда обосрались с HUMANKIND. Какой заработок, о чем ты?
Не думаю, что в моем многолетнем проекте будет какая-то устойчивая аудитория, я скорее как те братья буду пилить по кайфу (правда, они популярны).
Осталось только подобрать такой резиновый проект. Ибо у меня пока выходят другие резиновые изделия
>Толку мне от того что анон сделал?
Ты такие вещи больше сюда не пиши.
>>1068586
>в моем многолетнем проекте
>подобрать такой резиновый проект
Делай то, на что пульс учащается...
>Делай то, на что пульс учащается...
Сделать игру на потребностях человека это база баз. Но суть не в этом. Парадокс - мы симулируем часть мира или даже мир, но мы не можем сделать его бесконечно интересным.
Мы не можем очень сильно затягивать геймплей, мы не можем зациклить его, мы не можем изменить геймплей со временем из одной формы в другую.
Даже для людей, чья мотивация это эскапизм - мы не можем ничего для этого дать кроме как песочницу без цели (развлекай себя сам).
И это взрывает мозг - мы не можем создать бесконечный геймплей, даже для человека, который хочет этого.
Понятно что вот есть короткие вспышки мотивации - труд-награда, труд-награда, ощущение превосходство, азарт и прочее. Это основа всех игр и тут игра больше напоминает короткий фильм - посмотрел, получил свой заряд кайфа и все. Но что если человеку понравился мир и он хочет играть в него дальше? Чем заполнить ему этот мир? Да так чтобы это было так же интересно как и раньше? реиграбельность, но и она ограничена, да и начинать сначала, это как читать книгу дважды
Вечная проблема ендгейм контента. Сам термин даже раскрывает проблему, мол игра закончилась, что ты тут еще забыл, ну ладно, на тебе "затычку", дергай пока не надоест. Даже сетевая игра, это по сути затычка. Вот ты прокачался, а теперь иди в гильдии пинай босса (или других таких же), развлекайте себя сами, че морды скрючили?
Мы узники своего же мозга, мы не можем дать даже то что мы хотим.
А что геймплей? А геймплей никогда не меняется.
Майнкрафт, кстати, нанес колоссальный ущерб индустрии.
Воксельный мир - идеальный мир для большой рпг, но теперь из-за майнкрафта люди сразу же отождествляют этот мир с копанием под землю и постройкой зданий из накопанных блоков.
Представь что ты в скайриме или ведьмаке зарываешься под землю. Абсурд. А теперь сделай воксельный мир где ты не можешь копать!
>люди сразу же отождествляют этот мир с копанием под землю и постройкой зданий из накопанных блоков.
Потому что по факту он больше ни на что не годится. Комплексность реализации выше, перформанс хуже. Когда-то, в эпоху становления 3д, воксели рассматривались как кандидатура на мейнстрим, но полигоны выиграли, и это правильно.
Кстати есть еще одна известная воксельная игра, Teardown, автор которой как ни старался не придумал геймплейлупа кроме как "ломай быстре, или убегай от ломания быстрей".
>>1068683
>проблема ендгейм контента
Нахуй нинужон. Игры-жвачки с типа эндгеймом - рак современной индустрии. Прошел, получил экспириенс, прочувствовал историю, идешь к следующей. Годами залипать в одну дрочильню лишает тебя того богатого опыта, который ты мог бы получить, закрыв наконец дрочильню.
>Teardown, автор которой как ни старался не придумал геймплейлупа кроме как "ломай быстре,
Не знаю что у него, но мне думается - банальная лень, поигрался, потыкал, гештальд по вокселям закрыл, а наполнять мир это нудная рутина (да и нужен какой-то опыт или талант).
>Потому что по факту он больше ни на что не годится.
Хз, мега-миры. Каждый биом с определенным геймплеем. Относительно бесконечное приключение.
Есть в этом какой-то потенцевал, только не с такими блоками, чтобы по noise не скакать.
Ну и все видели, наверное:
https://www.youtube.com/watch?v=8OrZX347MoE
https://www.youtube.com/watch?v=Cq_dHmgcc7U
Во время рассвета майнкрафта не смог опробовать его нормально меня тошнило от копания, хз почему, какая-то форма клаустрофобии что ли но помню он давал определенную атмосферу окружающего мира, особенно его размеры.
Еще мне, кажется, 3Д моделить даже лоуполи проще, чем лепить из вокселей. Может я не прав.
>Годами залипать в одну дрочильню лишает тебя того богатого опыта, который ты мог бы получить, закрыв наконец дрочильню.
Суть не в этом.
Ты не можешь дать много геймплея, сохраняя прежнюю вовлеченность.
Ты не можешь зациклить, ты не можешь сменить геймплей, ты не можешь сильно затянуть. конечно, можешь все, но похерив уровень вовлеченности
>Сделать игру на потребностях человека
Ты неправильно понял смысл предложения.
Вот что тебя очень сильно увлекало в детстве?
Допустим, ты увлекался автомобилями. Настолько увлекался, что в возрасте 12 лет начал дрочить на порнографию, где обязательно есть какой-нибудь автомобиль, но у тебя есть предпочтения по маркам: некоторые возбуждают больше, другие меньше... И гоночные соревнования для тебя как секс, а если происходит авария - это как эрогуро - возбуждающая расчленёнка, даже если там люди не пострадали. Т.е. увлечение автомобилями в детстве выросло в нечто странное, извращённое, но в то же время не такое необычное, как может показаться - ты всего лишь "автомобильный фанат", тебя сложно отличить от "нормального" человека. Может быть, ты станешь автомехаником, чтобы прикасаться к запчастям автомобилей и копаться в их внутренностях? Может, захочешь стать гонщиком и участвовать в гонках. И наверняка, если ты не можешь контактировать с автомобилями в реальности, ты захочешь играть в компьютерные игры с автомобилями. И если ты разработчик игр, ты предпочтёшь делать игру про автомобили, даже если ниша и так переполнена. И продолжать разработку будешь как можно дольше, поскольку всё остальное как-то не привлекает. И ты наиграешь в свою гоночную игру много тысяч часов, поскольку тебя увлекает это - зачем прерываться?
Допустим, ты не увлекался автомобилями. Ты как-то наткнулся на проект про автомобили, который уже несколько десятков лет в разработке. Поиграл и не обнаружил ничего интересного. Ты хмыкаешь и не понимаешь: зачем разработчик тратит своё время? Неужели он не понимает, что его игра скучна и не затягивает дольше чем на пару часов? Но ты-то не обладаешь тем влечением, которым обладает этот разработчик игры, к автомобилям. И поэтому ты не способен получать то же удовольствие от его игры.
Поэтому, если ты действительно хочешь заниматься разработкой игры много следующих лет, ты должен покопаться в себе, в своих воспоминаниях, и найти определённую тему или темы, которые способны заставить твоё сердце биться чаще даже спустя множество лет, что прошли с твоего детства.
Иначе остынешь и бросишь игру, рано или поздно.
Какая же база. Схоронил.
Зачем ты такую большую Area делаешь, если у тебя используется Raycast для выбора предмета? Если выбираешь предмет рейкастом, то Area должна приблизительно повторять очертания предмета. Исключение тут - только очень мелкие предметы.
Альтернатива рейкасту: большая Area вокруг игрока, собирающая мелкие Area в список на экране. Что-то наподобие того, как это сделано в Genshin Impact.
Согласен полностью. Тоже давно пришел к этому, а когда начал более глубоко изучать тему - понял, что так делают многие. Вот, например, Сигэру Миямото, создатель The Legend of Zelda:
"В детстве Сигэру Миямото любил рисовать и раскрашивать картинки, исследовать ландшафты, окружающие его дом. Существуют истории, рассказывающие о его исследованиях пещер, озёр и прочих природных черт, которые потом сказались на его работе. Например, игра The Legend of Zelda была инспирирована в виде лабиринтов, похожих на дом Сигэру Миямото. Другой пример — это история персонажа Chain Chomp, который является врагом во многих играх с участием Марио. В детстве на Миямото напала соседская собака, которая сидела на цепи. Имя собаки «Cheru» впоследствии упоминается в игре Star Fox."
Также он любил всяких жуков рассматривать и в целом природу, это очень отражено во всех Зельдах, многими ее аспектами.
Все-таки игры - это искусство, а искусство - про выражение того, что у автора внутри. Это на самом деле как будто бы очевидно, нео кажется, многие упускают эту мысль. Особенно те, кто пилят свои движки или очень ударяются в код, когда работают одни. Разработчик игр - не программист. Он создает игру, а не исключительно код. Люди играют в игры, а не в код, музыку, нарратив или любой другой отдельный аспект игр. Игра - результат суммы слогаемых (всех аспектов игры) и немного больше, если эта аспекты друг друга дополняют и работают на пользу общей идеи. Идея и то, что мы хотим донести как разработчик, что хотим, чтобы игрок чувствовал - это очень важно. Не менее важно, чем любая другая часть разработки игры.
Мне вот 27 скоро, я пока безыгорный, но еще лет с 15 знал, что хочу стать разработчиком. Выучился на тех.специальность, работаю, жизнь куда-то уводит, создает препятствия. Какое-то время назад начал попиливать проектик на стороне, поначалу вообще ничего не складывалось, но стоило вспомнить то, что я любил в детстве и какие игры меня тогда впечатлили, я сразу понял - хочу, чтобы моя игра вызывала такие же чувства. И дело пошло с мертвой точки. Делайте то, что любите, а всякие изучения рынков, следование трендам, метрикам и прочие маркетологические занятия оставьте большим компаниям, которые иначе не могут ввиду своей структуры. И тогда все получится.
Ух насрал, повело что-то. Старею походу. Но все от сердца.
А я где-то читал историю первых покемонов: автор коллекционировал жуков в детстве и обменивался с друзьями, и так появилась идея первых покемонов. Пытались оформить это так, что покемоны "живут в GameBoy и путешествуют по проводу" или типа того.
Алсо, интересно, что раньше официально признавали возможность брака между людьми и покемонами во вселенной покемонов. Потом эту тему как-то замяли, несмотря на то, что покемоны - разумные существа, некоторые вообще почти как люди выглядят...
Ну а сегодня мы имеем огромное количество новых фетишистов-покемонофилов, что рисуют эро/порно с покемонами и делают фанатские игры, или даже самостоятельные покемон-подобные (порно)игры - благодаря тому, что играли в покемонов в детстве... Необычно здесь то, что Nintendo никак не пытается монетизировать это, а то бы уже секс-кукол делала.
И всё это началось с каких-то банальных жуков...
> Зачем ты такую большую Area делаешь
Лолшто? Вычисление игровых метрик по 5 секундам в пейнте? А мог бы игры делать.
> Зачем ты такую большую Area делаешь
Чтобы комод призывно приоткрывал ящички при приближении игрока, как бы показывая ему что он готов наполнить его рюкзачок своим горячим лутом.
а в чём более научное объяснение? сам планирую юзать гдскрипт, ибо он похож на питон, который я знаю хорошо. Типо там реально можно не подключать другие ЯП?
>а в чём более научное объяснение?
гдскрипт - наиболее удобный и быстрый для разработки, изменения на лету. Если его быстродействия не хватит тут уже можно подумать о переписывании конкретного куска например на c++, но такие ситуации возникают не часто, для большинства проектов хватает дефолта
(для чего не хватает?! ну например, ты придумаешь какую-то кастомную физику и миллион объектов или захочешь свои частицы через исчисление Верле (у меня от 200 объектов падал фпс), в общем это особый случай)
Слева вкатуны, которые ещё ничего не знают и не умеют. Подключать другие языки они не осилят; но гдскрипт как первый яп - супер простой. Глубокая интеграция с движком позволяет легко параллельно осваивать и основы программирования, и апи.
Справа мастера джедаи, которые знают движок, его сильные стороны и ограничения. Они не пытаются считать на нём >9k юнитов за кадр, но этого и не нужно. Годот - швейцарский нож, на все сколько-нибудь значимые задачи в нём уже есть решение. Остаётся лишь склеить всё это в единую игру - ну а с задачей glue code гдскрипт справляется на отлично. Нюанс: каждый такой мастер понимает, что если понадобится действительно экзотика, то надо писать модуль на плюсах; и склеивать его с остальным проектом всё равно через гдскрипт. И да, скорость разработки - это действительно важная причина самого существования гдскрипта.
Ну а посередине...
>мне было правда интересно почему люди выбрали именно его, на это должна быть реальная причина.
Единственный опенсурсный движок с адекватным редактором. Да и вообще, логика построения интерфейса и архитектура движка мне очень близки, в отличие от некоторых других, сделанных явно инопланетным разумом.
Лол, ты мем не понял и всё переврал. Поясняю суть мема. В основе лежит распределение баллов IQ по населению. Типа, у 2% меньше 70 IQ (низкий интеллект), у 2% больше 130 IQ (высокий интеллект), но большинство людей имеют около 100 IQ (средний). В реальности всё не так просто, но для мема это не важно. Мем заключается в том, что:
1) Слева находятся люди с низким интеллектом - не новички, а именно люди, страдающие дебильностью, в буквальном смысле дебилы - имеют какое-то поверхностное мнение, которое они в силу клинического недостатка ума не могут поменять, например - "раз все используют GDScript, то и я тоже буду", или просто плывут по течению своих импульсов;
2) В середине находятся так называется midwits, т.е. люди среднего ума, у которых достаточно мозгов, чтобы заметить подводные камни, которые не замечают дебилы, например - "GDScript медленный для тяжёлых алгоритмов и не имеет популярных в большом айти инструментов и современных языковых конструкций из популярных языков, поэтому ему нужно найти замену, и вообще отступы не дают легко копипастить код из интернета, а слабая типизация может усложнить отладку кода", и, чувствуя своё интеллектуальное превосходство, они стремятся изо всех сил доказать всем окружающим эту свою точку зрения;
3) А справа находится небольшое количество интеллектуально одарённых людей, которые видят не только то, что видят люди среднего ума, но гораздо больше - например, то, что для разработки игр важны не какие-то "инструменты и конструкции из популярных в большом айти языков" и даже не скорость выполнения скриптов, а лёгкость взаимодействия с движком, скорость написания, исполнения и изменения кода - то, что реально ускоряет работу, а не требуется в большом айти; поэтому их мнение на первый взгляд совпадает с мнением дебилов и отметается людьми среднего ума, но на самом деле оно наиболее рациональное.
Ну вот ты упоминаешь что ты играл в игру и не нашел в ней что-то (глубины или продолжения).
То есть, потребность в продолжении и деталей есть у всех. Я даже где-то писал >>1067374 → что большая часть мотивации это завуалированное желание играть в интересную игру, а не делать игру. Поэтому такая большая текучка среди вкатунов (неожиданно, но делать игру не тоже самое что играть).
Так вот - потребность в продолжении и глубины есть, но дать мы её игроку не можем. По сути, с момента старта мы получаем n-уровень вовлеченности игрока и он постепенно начинает падать - и никак его не вернуть, даже если человеку кажется что ему не хватает продолжения или глубины/деталей. В этом парадокс, ты можешь накрутить все что угодно, но ничто не возвращает "взад".
>фетиш автомобилей и устаревшие Фрейдизм
Первая аналогия, которая приходит с играми - это порно и дрочка. Мол подрочил и не интересно, хоть ты еще смотри. Но нет, это не тоже самое. Мы после дрочки не идем делать порно, мы не после дрочки не хотим глубины или продолжения событий. Типа знаешь, такой сидишь с сигаретой и думаешь, вот этот момент я бы переиграл, а тут бы добавил позу и декораций. Нет такого, тут что-то другое чем базовые потребности писоть/какоть.
Ладно, если Тодд Говард не нашел решение. Мне то куда.
В теории, если ты используешь рейкаст - у тебя есть его длина (ограничить луч), а значит потребность в area нет.
>то, что я любил в детстве
Проблема в том, что кроме этого ты ничего и не сможешь. Все силы ради одной игры? А если детский интерес пропадет, вообще больше ничего не будет?
Это как если бы ты за всю жизнь написал одну картину и такой все - это мой максимум.
Не думая что проблема мотивации/прокрастинации должна пересекаться с разработкой игр. Ты любое дело зафейлишь если нет дисциплины, укус детской собаки не поможет.
>"В детстве Сигэру Миямото любил рисовать и раскрашивать картинки,
Это же маркетинг, лол.
Когда человек задает вопросом какой инструмент выбрать - он скорее всего знает почему в этот момент ему нужно выбрать именно этот инструмент, например этот цикл узкое место и нужно избежать аллокаций, возьму-ка я тут С++.
Если у тебя таких вопросов не возникает, то не стоит вообще трогать тему выбора языка, скорее всего ты не будешь писать такие вещи, где потенциала GDScript будет не хватать.
Складывается такое впечатление, что ты ни дрочить, ни играть не умеешь.
Ладно, если тебе нравятся абстрактные графики - вот тебе абстрактный график.
>Мы после дрочки не идем делать порно, мы после дрочки не хотим глубины...
У тебя какое-то странное понимание дрочки. Никогда не хотелось сделать своё порно? Никогда не задумывался о том, чем мотивировались персонажи, и как они должны были действовать? Никогда не задумывался о глубинных взаимосвязях во вселенной, которые привели к тому, что произошло? Это абсолютно нормальное явление, называется "post-nut clarity", или "ясность ума после оргазма". Если у тебя такого не бывает - ну, штош...
Игры - это в буквальном смысле "мастурбация для мозга", со всеми побочками и эффектами; процесс игры заставляет сфокусироваться на ней так, что ничто кроме игры для тебя больше не существует; от успешной игровой сессии должно быть ощущение, сравнимое по силе с оргазмом (только без мышечных конвульсий); от неудачной игровой сессии ощущение, сравнимое с тем, как если бы ты 60+ минут безуспешно дрочил и так и не смог нормально кончить. Хорошая игра сможет затягивать в себя снова и снова своим пышным контентом и упругими механиками, даже если ты их уже тысячу раз видел и щупал, а плохая игра быстро оттолкнёт от себя даже в первый раз. Игра затягивает тебя в себя, обещая удовлетворить все твои животные позывы, но в реальности игра - это виртуальная секс-кукла, обман твоего восприятия, иллюзия достижения чего-то стоящего. Буквально мастурбация мозгами.
Так, собственно, что привлекает ТЕБЯ? Чего ты хочешь? Ты же тот, кто стратегию хотел делать? Настолько ли ты обожал играться с игрушечными солдатиками в своём детстве, что готов пилить стратегию про них на протяжении многих лет?
Суть мема это стёб над нормисама/среднечками, которые возводят проблему в абсолют. Типа если питон плох в дробилках, значит выкинуть вообще питон - взяв раст/плюсы/шарпы. Этот мем отображает отсутствие критического мышления и опыта у большинства.
В чем ошибки.
1) Взяв С++ ты не становишься сразу гуру оптимизации и не начнешь по дефолту писать быстрый код. Это отдельный хай-скилл. Я в юности писал Си обертки над пхп функциями и некоторые работали медленней, чем оптимизированные функции в пхп. Залезая в сорцы чтобы узнать почему - я сразу получал струю неопытности в лицо.
2) Профайлер показывает проблему не там где ты вообще думаешь и оказывается что С++ бы пригодился только для одного двух мест, а все остальное буквально оптимизация на спичках (крайне мала). В итоге профессионалы нередко используют связку С/С++ и питон/луа/итд. Потому что на динамикодресне писать бизнес логику удобнее и быстрее, а потери вообще незначительные (если есть нормальный JIT). По сути, для такого программиста интерпритируемые языки выходят как DSL-языки.
>Складывается такое впечатление, что ты ни дрочить, ни играть не умеешь.
Допусти до себя мысль, что ты возможно просто не понял о чем я.
Усталость тут точно не причем.
>не понял о чем я
Но ты тоже, похоже, не понимаешь, что я пытаюсь тебе объяснить.
Есть временные увлечения и есть то, к чему ты из раза в раз возвращаешься. Если ты где-то в интернете увидел совершенно новую игру и она тебя привлекала какой-то необычной идеей - у тебя возникает временное увлечение этой новой игрой. Да, оно постепенно сходит на нет, когда теряется новизна этой игры, потому что она привлекала тебя только лишь своей новизной. Но обычно у человека есть увлечения, к которым этот человек возвращается снова и снова. Как та же мастурбация и фетиши: ты эволюционировал, чтобы хотеть трахаться, и, пока ты здоров, ты будешь хотеть трахаться; а в детстве ты мог случайно подцепить что-то нестандартное, и в результате ты всю жизнь дрочишь не на/не только на сиськи и письки, а на что-то, на что у большинства людей никогда не встанет. С играми всё точно так же - есть вещи, которые будут тебя привлекать снова и снова, и снова, и снова - бесконечно, даже если ты уже наиграл много тысяч часов. Ты можешь устать от игры, но потом ты отдохнёшь и продолжишь дрочить в эту игру. Если ты не знаешь, какие вещи тебя будут привлекать, то это не проблема геймдизайна, а проблема твоего личного исследования твоих скрытых желаний и стремлений. Поиграй в разные игры, вспомни своё детство...
Или ты ожидаешь найти какую-то "простую" схему, чтобы ВСЕ твои игроки могли бесконечно играть в твою игру? Ну, тут только один вариант - мобильные гиперказуалки с механиками энергии, лутбоксов, гачи и т.п. Они специальными трюками заставляют игрока выработать привычку заходить в игру в определённое время и делать однообразные действия, чтобы игрок потом повторял эти действия, возможно, на протяжении многих лет, пока игра существует.
> Никогда не хотелось сделать своё порно? Никогда не задумывался о том, чем мотивировались персонажи, и как они должны были действовать?
Нет :)
>сравнимое по силе с оргазмом
Откуда вы достаете рудементы ранней психологии, даже его ученики критиковали за излишнее либидо в работе.
Понятно что в играх есть реализация примитивных потребностей, на то и расчет всей индустрии, особенно для подростков. Все аниме это стимуляция тех примитивов.
>Так, собственно, что привлекает ТЕБЯ? Чего ты хочешь?
Ну очевидно я не делаю игру для себя. Я не ищу вдохновения. Я ищу геймплей и механики на овер 100 часов.
Стратегии эксплуатируют такие потребности, которые заставляют играть человека овер 10 часов за раз. То есть, это нечто большее чем подрочить на аниме или фетиш.
>Но ты тоже, похоже, не понимаешь,
Как можно обсуждать "высокое", когда человек завис на первых ступеньках потребностей?
Я про самолеты, ты мне про самокаты.
Rubber duck debugging - работает всегда.
Вся эта пирамида, включая "высокое", есть у обезьян, дельфинов, птиц и т.д.
>>1068802
>излишнее либидо
А ты у нас импотент без либидо? Или ты из этих... нофаперов?
>Ну очевидно я не делаю игру для себя.
Тогда ты не сможешь делать её достаточно долго - потеряешь желание.
>Я ищу геймплей и механики на овер 100 часов.
Тебе уже тыщу раз говорили - выживалку делай или рогалик - база инди.
Выживалка: гриндишь-гриндишь, сделал кирку - гриндишь быстрее...
Рогалик: гриндишь-гриндишь, сдох - гриндишь с нуля, но умнее...
>Стратегии эксплуатируют такие потребности... овер 10 часов...
>То есть, это нечто большее чем подрочить на аниме или фетиш.
Сразу видно новичка, который ни разу не занимался edging 18 часов подряд.
Стратегии - это про власть и доминирование. То есть примитивный инстинкт.
Обезьяна побила других обезьян, залезла на горку, бьёт в грудь - "у, у" - кайфует.
Лысая обезьяна в очках "побила" виртуальных обезьян, бьётся в экстазе - кайфует.
Разница только в сложности действий - побить кулаками или хитроумным планом.
Пока ты ищешь твоё идеальное "высокое", ты не замечаешь реального, земного.
>А ты у нас импотент без либидо? Или ты из этих... нофаперов?
Ты не должен быть тем кто употребляет игры, ты должен быть тем кто их производить.
Никто не утверждал, что дисциплина не нужна. Ты это додумал.
Как изменить тему дефолтного тултипа в годоте, когда наводишься на элементы интерфейса? Либо я в шары ебусь либо в настройках темы его нет, и хуй знает как на него сослаться через код.
>Вся эта пирамида, включая "высокое", есть у обезьян, дельфинов, птиц и т.д.
Ну пирамида как бы показывает путь до самоактуализации. Но, а каком процессе созидание может идти речь, когда у тебя все мысли о еде или сексе или о хулиганах, которые ждут в подворотне.
>А ты у нас импотент без либидо? Или ты из этих... нофаперов?
Эта потребность удовлетворена, нет необходимости ставить её во главе всего.
>Тогда ты не сможешь делать её достаточно долго - потеряешь желание.
Многолетние проекты - это мое хобби.
>Стратегии - это про власть и доминирование. То есть примитивный инстинкт.
Все игры эксплуатируют ту или иную потребность.
Я вообще не отрицал, я говорил что невозможно реанимировать вовлеченность. Она падает с самого начала и никак это не исправить, как если бы ты во время дрочки - переключал видос и у тебя вообще все падало бы (раз тема секса тебе ближе).
>Пока ты ищешь твоё идеальное "высокое", ты не замечаешь реального, земного.
Я уже нашел. Правда придется делать сетевую, мне это не нравится.
>В детстве Сигэру Миямото любил рисовать и раскрашивать картинки, исследовать ландшафты, окружающие его дом.
Оооо я уже знаю какая будет паста обо мне.
В детстве Анон любил жить в серой хрущевке, дни проходили однообразно, дом, школа, дом. Все серо и уныло, кроме моментов когда отчим приходил вечером пьяный домой и устраивал взбучку. Тогда мир менялся полностью и анона наполняли яркие эмоции ....... так и появилась на свет его популярная игра про самосбор, вдохновленная его прекрасными юными годами.
Документацию читай:
https://docs.godotengine.org/en/stable/classes/class_control.html#class-control-property-tooltip-text
>The default tooltip includes a PopupPanel and Label whose theme properties can be customized using Theme methods with the "TooltipPanel" and "TooltipLabel" respectively.
Можно даже создать свою собственную сцену-подсказку...
>показывает путь до самоактуализации
>когда у тебя все мысли о еде или сексе
Да бред всё это. От того, что ты только что нажрался, ты не перестанешь рисовать натюрморты - их не от голода рисуют, а от обжорства и безделья. От того, что ты только что натрахался, ты не перестанешь лепить скульптуру голой бабы - их не от недотраха лепят. И так далее. Ты пытаешься сказать, что человек якобы ищет чего-то "высокого", но в реальности человеком движет примитивное "животное". Смотришь на звёзды? Ты просто хочешь перетрахать всех инопланетянок и нажраться инопланетной еды. Смотришь в океан? Ты просто хочешь перетрахать всех русалок и нажраться океанической еды. И так далее. То, что ты выдумываешь себе какие-то возвышенные мотивации, значит только то, что ты любишь прикрывать возвышенными мотивами реальные. Давно уже доказано, что мозг активно врёт сам себе, выдумывая благовидные причины, которых на самом деле не было - просто потому что это выгодно - уметь выдумывать благовидные причины своих действий для объяснения своих поступков. Представь себе, что ты украл что-то и попался - если ты честно скажешь, что сделал это, чтобы выпить водки, то тебя накажут, а если ты соврёшь, что у тебя больная мать и ты хочешь приготовить ей лекарство, которое в числе прочего содержит водку - могут разжалобиться и отпустить. И твой мозг это делает бессознательно сам с собой - придумывает благовидные причины на каждое своё действие. Но когда ты об этом уже знаешь, ты можешь научиться подлавливать себя на лжи и пытаться докопаться до истинных причин...
>придется делать сетевую, мне это не нравится
Лол. Не страдай фигнёй, ты даже сингл не сделал ни разу. Чтобы сделать полноценную жизнеспособную многопользовательскую онлайн игру, нужно не только создать надёжный сетевой код и чётко сбалансировать геймплей, чтобы он был честным и интересным для всех игроков (это очень сложно), но ещё и наваливать регулярных обновлений, чтоб игроки не разбегались, рулить сообществом игроков, разрешать конфликты и прочее. Но чтоб всё это могло начаться, тебе нужно хотя бы первую партию игроков где-то найти. Одиночка может и справится, но ценой очень больших усилий - нужно ли тебе это? Это уже не хобби, а работа. Хобби ты занимаешься время от времени под настроение, можешь хоть полгода не притрагиваться - а онлайн-игра без поддержки разрабом за это время просто умрёт и уже не воскреснет. Тем более тебе самому это не нравится, а, значит, и мотивация продолжать у тебя быстро обмякнет.
> их не от голода рисуют, а от обжорства и безделья.
Так именно и работает пирамида Маслоу, ты направления перепутал.
>сделать полноценную жизнеспособную многопользовательскую онлайн игру, нужно
Всю жизнь, что я делаю это пишу бэкенд, я убежал (в хобби проектах) в геймдев, потому что устал от бэкенда. Я не хочу делать сетевую, не потому сложно, а потому что надоело. Я больше кроме бэкенда ничего и не умею.
>Не страдай фигнёй, ты даже сингл не сделал ни разу.
Безыгорка, снова.
Это у вас бзик на незаконченные проекты, у анальников проблем с релизами нет (и с тем чтобы дропнуть пет-проект. Это даже облегчение, что это просто пет-проект).
>Но чтоб всё это могло начаться, тебе нужно хотя бы первую партию игроков где-то найти
Это определяющий фактор. То есть, геймплей вынужден будет подстраиваться. Хз, я только придумал. Возможно будет только рынок с ботами, остальное сингл с какими-то статистиками для писькомерства. Это точно не чувствительное к онлайну, но нужно с кем-том мериться будет, без пвп.
>Одиночка может и справится, но ценой очень больших усилий - нужно ли тебе это? Это уже не хобби, а работа
Я тот типаж людей которые паяют платы и строят самолеты в гараже. Только я ковыряю код, с недавнего времени графику немножко. У меня нет цели - скорее до релиза.
Я с большой вероятностью опубликуюсь в попенсорс, если не дропну или не решу повышать качество до стимовской игры (это прям маловероятно). Так что возможно увидишь и даже звездочку поставишь (играть в это точно будет невозможно).
Это ИИ, который реально всем нужен, а не вот этот весь нейрослоп с 100500 полигонами на шестом пальце дженерик аниметян.
Я не помню что там в сабнавтике, но как совет, посмотри какое-то общее видео по UI в годоте, а потом по кирпичикам попробуй собрать сам.
https://www.youtube.com/watch?v=5Hog6a0EYa0
Это сложнее, но в будущем ты будешь более свободен в своих решениях.
И помни, что из кода ты можешь достучаться до каждой ноды (получить доступ к свойствам/методам, как в инспекторе)
> предметы размером в 1 ячейку и размером 2x2? Где найти гайд по таким инвентарям?
Давно, еще на трёшку видел. Но что гайды. Ты просто логически подумай, как это сделать? Это же не сложно.
>>1068848
Я пробовал float но чет шляпа. Проще сделать сетку в сетке.
Если размер большой - он занимает всю сетку, если маленький то у нас "сетка в сетке".
Может есть лучше решение, я не гуру.
Зачем тебе сетка в сетке? Ты так не сможешь размещать объект 2 на 2 не внутри заложенных дочерних сеток. Сделай одну большую, вот тебе матрица. Хочешь положить предмет 2 на 2 в ячейку - проверяй свободность ячеек (i;j), (i+1;j), (i;j+1), (i+1;j+1).
Но есть решение проще я его не знаю, но оно есть
Я уже смотрел про ноды. Но такой ноды не обнаружил.
>>1068852
Возможно это не сложно. Логически я вижу несколько реализаций. Просто, для того я и беру движок, что бы не изобретать велосипед, не? Должно же это быть как то предусмотрено.
https://staticdelivery.nexusmods.com/mods/1155/images/490/490-1590062841-404643145.jpeg
Вот пример как это должно выглядеть
>Ты так не сможешь размещать объект 2 на 2
Я уже разместил на пикче.
Просто это надо делать кодом.
Тогда сеткой не подойдет.
Простое
- Отсортировать по размерам.
- Размещать, помечая ячейки как занятые в строках и столбцах (ось x,y).
- Переходить на следующую свободную ячейку в строке (ось x)
- повторить
> Просто, для того я и беру движок, что бы не изобретать велосипед,
Движок тебе дает АПИ, а дальше сам. Это не конструктор игр. Мы делаем слишком разные игры, чтобы всем угодить.
Так же это слишком специфичное меню, для затягивание геймплея (заставить игрока туда сюда плавать, отнимая у него размер инвентаря).
Тут слишком маленький список, может делать как хочешь, оптимизация не нужна, хоть ты 4-5 раза пройдешься по двухмерному массиву, все равно будет быстро.
Сделай две вакансии.
Сейчас бы мечтать делать кабану мобильные доилки. Одни и те же, каждый день, как макака в загоне.
>Делать кабан кабанычу
Лучше дома сидеть и опыт получать в том, что тебе нравится. Чем ебашить пятидневку на заводе как у меня сейчас.
>в том, что тебе нравится
С чего ты решил, что будешь делать что тебе нравится и хочется? Лол.
Ты возненавидишь, то что любил.
> я уже в пижаме
Ну тогда вот тебе видос на сон грядущий
https://www.youtube.com/watch?v=ByL17d28x9Q
Завтра обязательно расскажи, насколько он полезен был.
>Так именно и работает пирамида Маслоу
Твоё утверждение: "кроме секса есть что-то высокое, но что - не скажу, вот пирамида".
Моё утверждение: "люди даже после секса, на вершине пирамиды, делают ради секса".
>Всю жизнь, что я делаю это пишу бэкенд
>Я больше кроме бэкенда ничего и не умею.
Именно поэтому тебе не следует делать сетевую игру. Сетевая - это не только сервер.
>Это у вас бзик на незаконченные проекты
Но ты сам только что сказал: "кроме бэкенда ничего не делал и ничего не умею".
>Я с большой вероятностью опубликуюсь в попенсорс
Молодец.
>1 вакансия активная
Посмотри на это с другой стороны:
- вакансий Unity много и они висят открытыми месяцами, потому что никто не подходит;
- вакансии Godot открываются и сразу закрываются, потому что все годотеры - крутаны.
Гордиться надо. Это вам не это. Godot даёт +9999% к навыкам программирования.
>Почему то все делают инвентарь с предметами одного размера.
Потому что это базовый инвентарь, подходящий большинству игр.
>А что если я хочу сделать типа как в сабнавтике
Тогда ты хочешь хорошенько помучить игрока.
>Где найти гайд по таким инвентарям?
Давай я тебе вкратце распишу. Тетрис делал? Вот это оно и есть.
У каждого предмета есть свой мини-массив ячеек, типа такого:
>class_name Item extends Resource
>var cells: Dictionary[Vector2i, Item]
У инвентаря есть свой, точно такой же по формату массив:
>var cells: Dictionary[Vector2i, Item]
А ещё у инвентаря есть методы наподобие CRUD.
Для добавления предмета:
>func can_place(item: Item, at: Vector2i) -> bool:
>_ for key in item.cells.keys():
>_ _ if (at + key) in cells:
>_ _ _ return false # ячейка уже занята
>_ return true # все требуемые ячейки свободны
>func place(item: Item, at: Vector2i) -> bool:
>_ if can_place(item, at):
>_ _ for key in item.cells.keys():
>_ _ _ cells[at + key] = item
>_ _ return true # положили предмет
>_ else: return false # не получилось
Для извлечения предмета:
>func can_take(item: Item, at: Vector2i) -> bool:
>_ for key in item.cells.keys():
>_ _ var cell := at + key
>_ _ if cell not in cells or cells[cell] != item:
>_ _ _ return false # нет нужного предмета
>_ return true # предмет есть, можно брать
>func take(item: Item, at: Vector2i) -> bool:
>_ if can_take(item, at):
>_ _ for key in item.cells.keys():
>_ _ _ cells.erase(at + key)
>_ _ return true # извлекли предмет
>_ else: return false # не получилось
Для реализации стопок нужно ещё два массива:
>var items: Dictionary[Item, Vector2i]
>var stacks: Dictionary[Item, int]
Или что-то вроде того. Можно классы навернуть...
Далее ты хочешь прикрутить всё это к GUI своей игры:
1. Делаешь "сеточный" рендерер с шагом по размеру ячейки:
>var cell_size := Vector2i(32, 32) # в пикселях
>var inventory: Inventory # чего вообще рендерим-то
>func _draw() -> void: # блаблабла, ну ты понел, дальше сам
2. Цепляешь обработчики ввода мыши, типа _on_gui_input...
3. В обработчиках теребонькаешь свой CRUD в инвентаре...
4. Тестируешь...???
5. Восхитительный гуй!
А главное, главное - это не забывать обмазывать всё Tween'ами.
>>class_name Item extends Resource
>>var cells: Dictionary[Vector2i, Item]
Дополнение: потомки RefCounted (Resource) имеют встроенный счётчик ссылок, который сходит с ума при создании случайных "цикличных" связей, типа если A ссылается на B, а B ссылается на A, из-за чего могут быть утечки памяти, т.к. счётчик не может опуститься до нуля. Чтобы это исправить, можно использовать WeakRef (сохраняют ссылку на объект, не увеличивая счётчик ссылок) или уменьшать счётчик вручную.
Либо пойти классическим путём и использовать int, который играет роль ID-шника предмета. То есть где-то у тебя в проекте есть "база всех предметов", хранящая соответствие ID == предмет:
>var items: Dictionary[Item, int]
И дальше ты используешь этот int-овый айдишник для всех операций с предметами. Из минусов здесь то, что ты вынужден заранее зарезервировать номера предметов, что можно обойти с помощью специального типа StringName, который абстрагирует нас от числовых ID, позволяя использовать в качестве ID любые строки практически без потери скорости операций.
Может показаться, что достаточно bool (занято/не занято), но самое главное свойство данного "тетрисного" инвентаря в том, что предметы могут иметь буквально любую форму, и мы не должны делать никаких предположений о том, принадлежит ли какая-то занятая ячейка тому предмету, который мы хотим взять, или нет...
А, блин, я ещё не заметил важный нюанс: если в инвентаре могут быть дубликаты предметов без стопок, тогда у них должны быть уникальные IDшники. Эти уникальные ID никак не связаны с типами предметов, т.к. они уникальны для конкретного инвентаря... Да, та ещё головная боль...
Короче. Лучше в это говно не лезть, а если очень хочется - то тщательно тестировать. Все игры, в которых я данный тетрисный инвентарь встречал, были дико глючными и тормознутыми несмотря на примитивнейший GUI. Если ты совсем новичок, то вряд ли у тебя с первой попытки получится лучше, чем у этих "ветеранов геймдева"...
На тебе отступов на будущее, про запас.
_ _
_ _ _
_
_ _ _ _
_ _
_ _ _
_ _
_
>мог просто демку скинуть
Как я тебе её скину, если я её не делал? Я в форме поста на дваче код пишу. Без подсказок.
Нет, конечно, я мог бы сделать такой инвентарь для теста... Но тетрис я уже когда-то делал.
>>1068912
Предлагать двачеру помыть полы - некультурно. Ты же повредишь слой пыли в его берлоге.
>>1068913
Кот - лучший пылесос. Просто берёшь и возишь его по полу. Кот кайфует, пыль собирается.
>>1068914
Ты перепутал, но я с тем аноном согласен. Вам помочь пытаешься, а вы ещё критикуете...
>Как я тебе её скину, если я её не делал? Я в форме поста на дваче код пишу. Без подсказок.
Это невозможно читать, есть же pastebin / скрины с редактора.
>если в инвентаре могут быть дубликаты предметов
Я тут подумал - можно организовать инвентарь так:
- ItemTemplate описывает характеристики предмета
- ItemStack описывает экземпляр(ы) предмета
- Inventory работает с ItemStack, обращаясь к:
>item.template.shape
И заполняя cells ссылками на уникальные ItemStack.
А shape может быть простым массивом с Vector2i.
>>1068917
>Это невозможно читать
Сразу видно ньюфага...
>есть же pastebin
Он мне не нравится.
>скрины с редактора.
Код набран в форме поста двача.
Там всего несколько строчек с комментариями.
Рисовать сетку не лень, а написать в пастбине/заскринить - тяжело.
Понятно
Ты разве не понимаешь, что те кусочки кода в принципе не предназначены для копирования? Это просто чтобы в общих чертах уловить суть идеи: два массива, один из них - это шаблон, другой - реальные ячейки, и шаблон используется как трафарет для проверок, вставки предмета, удаления предмета и т.д. Так зачем мне писать этот код где-то, откуда ты его мог бы побыстрее скопировать, если этот код даже не предназначен для работы?
В программировании есть термин "псевдокод" - код на абстрактном ЯП. Вот это что-то уровня псевдокода.
Шаблон не нужен у нас всегда прямоугольные формы (2х2, 2x3) Это не тетрис с сложными формами. Основной замысел там в обтекании предметов. Насколько я помню там что-то типо автосортировки всегда.
Только у меня вроде тут мод на увеличенный инвентаря, по дефолту там 6 горизонтальных ячеек. Но зато видно как сортируется.
В общем, там автосортировка (руками не подвигать). Сортируется по горизонтали X с обтеканием, от большего к малому, собственно, как я и думал. кому не пофиг
НО (пик2) есть возможность перетащить с заменой из другого инвентаря, при этом мышку центрирует на предмете и дергает, что не очень приятно, хотя не критично. Как-будто можно было просто сделать перетаскивание предмета, все равно все на автосортировке.
(пик3) Игрушка с гигапотенциалом, жалко что пустая и для попила бобла.
>Так зачем мне писать этот код где-то, откуда ты его мог бы побыстрее скопировать, если этот код даже не предназначен для работы?
Когда-нибудь ты поймешь что можно даже псевдокод заскриншотить. Но не сегодня
Забегал тут один, у него персонаж не останавливался.
Программирование это тайное знание элиты, маглам питон недоступен, забудь.
Я так-то сениор пиздабол, могу и сам кодить, но вайб кодить веселее.
>в контекст движка чтобы она мне и ноды со сценами создавала.
Пытался в такое, нейронка выдает кашу пиздос, нирикамендую. Максимум, что кое-как получается, это выбить из нее виртуальную структуру сцены, которую потом создаешь сам руками и правишь-исправляешь.
Странно, .tscn же на тексте, по идее нейронку прикрутить не должно быть проблем. Надо поискать мож кто уже запарился.
>Странно, .tscn же на тексте
Да, и она сгенерирует tscn, но у меня он всегда он неработоспособен, вида "ну вроде как-то так, ну хуй его знает". А руками исправлять tscn это дно.
Думаю у них недостаточно трейнинг даты по tscn и тому, как оно соотносится с игровым миром.
Я прост заебался уровни дизайнить, аж рука болит, и хотел на нейронку скинуть. Хуй крч.
> У меня каким-то фигом оказалась есть сабнавтика.
Потому что это классная игра. Ты купил её и играл в неё.
А потом ты состарился и сошёл с ума, мотому что оказывается, теперь у тебя она
> пустая и для попила бобла
Выдыхай, бобёл.
Пичаль-бида, вот так упрёшься в стену несколько раз на реальных проблемах с нейронкой и потом смешно читать как ИИ ВОТ УЖЕ СКОРО программистов заменит. Быстрей бы блять уже, не хочу сам в этом кале разбираться, пусть нейропидор вилкой делает, а я просто командовать буду.
Как индюк я не против деградации геймдева, но как игрок я с таких как ты в акуе.
Думал игры с развитием железа буду только становиться сложнее, но нет, с одной стороны мобильные доилки с нереальной рекламой. С другой игры обёртки, где замысел пережить стимовские 2 часа или дать картинку для стрима.
Когда ты умер, ты этого не осознаёшь, только твоим близким тяжело. То же самое происходит, когда ты сошёл с ума.
Помни, что нейронка выдает нечто среднее имеющее отношение к теме. Попросишь у нее скрипт написать, полчишь мешанину из 3 и 4 версий. Потом придешь сюда спрашивать хули не работает.
ИИшка пишет промт для ИИшки, ЭТО СИНГУЛЯРИТИ почаны!
Как же я кринжанул с этого стиля письма. Когда человек так пишет это все как-то списывается на лень и локальный сленг, но только увидев как нейронка повторяет "реальные сетапы" и "юзать чтобы кайф был" осознаешь во что мы язык превратили. И да, я знаю что мне тоже лень искать литературный аналог слова "кринжанул".
>у нас всегда прямоугольные формы (2х2, 2x3)
Это в сабнавтике, а речь шла про общий случай... В наиболее общем случае этот инвентарь по сути своей "Тетрис без гравитации", все его проблемы решаются аналогично Тетрису. Так что давай, делай Тетрис...
>Основной замысел там в обтекании предметов
Это не замысел, а quality of life. По сути тебе не нужна автосортировка, если ты делаешь тетрис-инвентарь: игроку хочется страдать крутить предметы руками.
>>1068950
>жалко что пустая и для попила бобла
Они сделали достаточно много контента в первой, на несколько десятков часов как минимум. А уже когда взлетели, начали пилить бабло "второй частью". Ну, нормальная стратегия. Намного хуже, когда разраб выпускает 100500 DLC по цене полной игры (Sims, различные гоночки, строительные симуляторы), или заставляет платить микротранзакции в самой игре (практически любая ММО и все гиперказуалки).
>гигапотенциалом
Что ты имеешь в виду? Система строительства хоть и прикольно выглядит, но весьма бесполезная...
Главный косяк Subnautica - это фейл подлодки. Они планировали её расширять и улучшать всякими стыкующимися модулями, но у них не получилось. Кажется, во второй части добавили "вагоны", что стыкуются с "локомотивом", но выглядит тупо.
>>1069025
>игры обёртки
Если лично тебя игра не затянула - ты не в её ЦА. Интересного контента в первой Subnautica много, достаточно для многих десятков часов игры.
>Они сделали достаточно много контента в первой
Начальный вайб - хороший. Проработанная первая локация, крушение, красиво, детально, научно-фантастичненько.
Тебе даже дают строительство базы, но в реале база тебе и не нужна, мир оказывается пустой. Используются элементы затягивания геймплея, дальние локации практически просто террейн, ну и растянутый/затянутый сюжет, чтобы что-то было.
У них было уже все, билдинг базы, выживач, крафт, гринд, вайб исследования миров - все заполняй мир, пох даже через ДЛС или новую часть. Но нет, они просто скукоживают все наработки выживача/опенворда до сюжета (медленно доплыви - узнай тайну) и все.
Вторая часть тупо копия, они даже скорость этого водного скутера занизили чтобы удлинить перемещение, опять же пустой мир и сюжетка (я еще её неправильно прошел, доигрывал уже на ютубе).
>Что ты имеешь в виду? Система строительства хоть и прикольно выглядит, но весьма бесполезная...
Вот в этом и нонсенс. Тебе незачем строить базу, она там как пятое колесо (хотя в тот момент ты еще не знаешь об этом скаме)
>шарить анимации
Основной туториал по ретаргетингу:
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/retargeting_3d_skeletons.html
Теоретически, можно прямо в коде это всё делать.
По поводу костей: можно игнорить лишнее, можно добавлять нужное, можно комбинировать. Как тебе покажется удобнее, так и делай. Всё равно твой риг получится, скорее всего, чем-то нестандартным. У AnimationTree много настроек для миксования, там возможно соединять и игнорировать анимации...
https://docs.godotengine.org/en/stable/tutorials/animation/animation_tree.html
>процедурно, через что-то типа jiggle bone
Ну, есть вот такая дрожалка без физики:
https://docs.godotengine.org/en/stable/classes/class_springbonesimulator3d.html
Или делать на основе физических костей:
https://docs.godotengine.org/en/stable/classes/class_physicalbone3d.html
Базовый туториал (всё сложнее, чем кажется):
https://docs.godotengine.org/en/stable/tutorials/physics/ragdoll_system.html
Ещё наконец-то сделали нормальный IK в 4.6:
https://docs.godotengine.org/en/latest/classes/class_ikmodifier3d.html
Всё это, кроме физики, сидит на модификаторах:
https://docs.godotengine.org/en/latest/classes/class_skeletonmodifier3d.html
Подробнее, от главного разработчика системы:
https://godotengine.org/article/design-of-the-skeleton-modifier-3d/
https://godotengine.org/article/inverse-kinematics-returns-to-godot-4-6/
По производительности: пока у тебя всего несколько персонажей, никаких проблем не будет. Для толпы из нескольких десятков нужны оптимизации, которых в движке, естественно, нет - но можно сделать самому. Исходя из твоих хвостов и jiggle, ты делаешь что-то эротическое, поэтому вряд ли понадобится толпа...
Класс, спасибо за ссылки. Но я не эротическое делаю, а свиткоподобное. Просто куда сейчас без джиггла, он ведь даже для длинных волос нужен. И меня в первую очередь волнуют подводные камни, боюсь что придется потом переделывать кучу контента если что-то не учел, поэтому пытаюсь заранее все предусмотреть. Про ретаргетинг я уже посмотрел видос тут пока, и вроде получается что не так важно вообще какой скелет, все равно в движке он по сути свой, только импортировать может быть сложнее или проще, хорошо если так.
>Тебе незачем строить базу
>>1069050
>но в реале база тебе и не нужна
Базы нужны и важны - они позволяют добывать и складировать различные ресурсы в разных биомах, избегая излишнего перемещения через всю карту. Естественно, эта механика работает только лишь благодаря ограничениям: в ванильной игре ты не способен перетаскивать в карманах гигатонны различного хлама, на тебя всегда давит нехватка кислорода, энергии, запчастей для ремонта и т.д. Соответственно ты строишь по всей карте много миниатюрных баз, куда можно залезть, подышать, покушать, сменить батарейки, выгрузить лут и продолжить работу снаружи, не бегая далеко. Это основной геймплей, он фановый и его хватает на несколько десятков часов как минимум.
Исходя из твоих слов, ты с порога не разобрался в геймплее, накатил васянкомодов на отключение ограничений, полетал по карте на жопной тяге без ограничений и такой: "фу, чёт скучно". Фактически испортил свой игровой опыт абьюзингом ЧИТОВ, и жалуешься на разработчиков почему-то. Дурак?
>Используются элементы затягивания геймплея
Это называется игровой баланс, и ты его сломал, т.к., с высокой вероятностью, ты не входишь в ЦА игры...
>дальние локации практически просто террейн
Там весь основной контент игры спрятан на глубине, в которую сложно погрузиться из-за ограничений и давления воды, но ты этот контент, видно, не видел.
>все заполняй мир, пох даже через ДЛС
Новых рыбов показывать? И так много рыбов...
P.S. Я даже первую часть не прошёл сюжетно, но я наигрался за несколько десятков часов и мне даже хотелось продолжить, но... У меня боязнь глубины. Физически страшно было спускаться глубже, хотя я осознавал, что в худшем случае потеряю лут в игре. Офигенная иммерсивность за счёт ограничений.
> поэтому пытаюсь заранее все предусмотреть.
Самая реалистичная проблема - потеря интереса к проекту.
Поэтому делай пока делается, как сказала бы нейронка - чтобы по кайфу было. Вся эта фигня о которой ты переживаешь - приходит только с опытом.
мимо, ничего не знаю про анимацию, но понимаю немного за жизнь.
Не, у меня другое. Перфекционизм и вот эта вот боязнь. Начинаю делать что-то такое базовое, что всегда пригодится - и все супер получается, но как только надо принимать решения ограничивающие будущие возможности, так сразу ступор. При этом, что самое смешное, каждый раз все равно с нуля начинаю, и на опыте проскакиваю то, о чем парился в прошлый раз, но потом опять во что-то новое упираюсь. То с оптимальной топологией суставов мозги себе ебал, то с UV-разверткой, теперь вот очередь костей пришла.
>Просто куда сейчас без джиггла
Даже в некоторых топовых АААА сессионных онлайн шутерах нет/не было тряски и все сисяндры прибиты гвоздями к торсу. ИРЛ сиськи с бюстгалтером и, тем более, в бронелифчике трястись не должны... А хвост требуется анимировать вместе с ногами, поскольку хвостатые животные используют его для баланса и, в некоторых случаях, даже как третью конечность. Болтающийся хвост будет смешон, как вялый член.
Подводный камень процедурной тряски: ей нужно настраивать ограничения и завязывать её силу на максимальное ускорение персонажа. Если геймплей позволяет рвануть 30 км/ч с места, то сиськи могут прорваться сквозь грудную клетку на 2 метра назад. Значительно проще будет анимировать их вручную.
>боюсь что придется потом переделывать
А ты сначала сделай минимальный набор на очень примтивных мешах, а потом окунайся с головой в сложности. Сделай квадратную тентаклю с одной цепочкой костей, анимируй, импортируй в движок, поиграйся с ней, засунь эту тентаклю куда-нибудь. Разберёшься намного быстрее, чем с туториалом.
Алсо, переделывать проще, чем делать всё с нуля. Некоторые игры вообще движок меняют и ничего. Изобретать новое - вот что сложно, а ещё >>1069065
>потеря интереса к проекту
- главный подводный камень инди-разработки. Без начальника и без чётких перспектив в будущем ты замучаешься каждый день садиться и работать.
>>1069067
>Перфекционизм
Популярный мем в сообществе Godot на Reddit:
>Just make it exist first, you can make it good later.
>Соответственно ты строишь по всей карте много миниатюрных баз, куда можно залезть, подышать, покушать, сменить батарейки, выгрузить лут и продолжить работу снаружи, не бегая далеко.
Этого вайба там нет, ты сразу же получаешь там какой-то мини корабль и плаваешь на нем (в нем дышишь и погружаешься). Тебе даже не нужен тот экзоскелет и те гигаруды (но они создают впечатление, что в игре нужен будет гигагринд и вообще многое впереди). И почти сразу получает потребность в том гигакорабле, который собирает все стены в игре и из него ничего не видно, плюс еще темно.
Смешно, но это похоже на симулятор какашки. Тебе ничего не видно, ты двигаешься очень медленно, ты бьешься об стенки в кишке и в конце ты выходишь на свет и чувствуешь облегчение (я еще потерялся, хоть кишка линейна, там есть момент с двумя переходами, я спустился в один и поднялся обратно в другой).
Про корабль базу маркетинговый буллшит, игра же делалась по фидбэку, надо было кормить иммерсивностью. В реале погружение на том кораблей выглядит так как-будто они уже торопились закончить игру (поэтому получился симулятор какашки). Почему буллшит? Да потому что тот корабль был уже лишним, он не вписывался в размеры игры и даже на малой глубине. Ну и карта очень маленькая, да и плавать куда-то нет смысла. Там есть мир - но нет геймплея зачем он весь нужен.
>Исходя из твоих слов, ты с порога не разобрался в геймплее
Я максимально пытался продлить вайб, ты же видел базу, я собирал, строил, думая что у меня будет еще контент, а не симулятор тонкой кишки с концовкой.
>васянкомодов
Я поставил только мод на инвентарь, потому что скам (не помню почему, вроде игра заставляла плавать менять инструменты, что вообще не умножало иммерсивности исследования мира, просто затягивание на ровном месте).
>Перфекционизм
Больше похоже на ОКР, по два раза не проверяешь закрытую дверь?
>в некоторых топовых АААА сессионных онлайн шутерах нет/не было тряски
Это скорее вопрос цензуры и этики западных разрабов. У японцев без тряски никуда даже в детских играх.
>Болтающийся хвост будет смешон
Хвост волос это тоже хвост. Фуррятину не люблю, но возможно какие-нибудь кобольды или скавены потом еще будут.
>А ты сначала сделай минимальный набор на очень примитивных мешах
Делал еще в третьем годоте, а в четверке оно сломалось. Ты там про 4.6 написал, придется опять перекатываться, но это попроще чем основная версия.
>переделывать проще
Смотря в каких количествах. Вот запилю я скажем пару десятков вариаций пропорций тел, волос, брони, итд итп, а потом окажется что все заново надо ригать. Уже так наебался однажды наделав через shape keys в блендере вариаций, а потом оказалось что они с миррор модифаером не экспортируются и надо по-одному все применять.
Про перфекционизм и постоянство в общем дельно, но с этим я кое как научился бороться уже, а со ступором от выбора пока не очень.
>>1069073
Есть такое тоже.
>Смотря в каких количествах. Вот запилю я скажем пару десятков вариаций пропорций тел, волос, брони, итд итп, а потом окажется что все заново надо ригать. Уже так наебался однажды наделав через shape keys в блендере вариаций, а потом оказалось что они с миррор модифаером не экспортируются и надо по-одному все применять.
Родина дала тебе custom resources с скриптами и нейронки, которые могут легко одно говно конвертануть в другое, носи говорит, звездочки, а не терпи
Дораха, да и не люблю с человеками возиться. Легче самому код писать. На крайняк буду по-старинке код в курсоре, ноды буду сам ворочать.
>>1069039
Да я в курсе, но там надо уметь промптить и где надо самому дописывать.
>>1069042
Затем что уже получил этот ответ от нейронки, решил удостовериться у человеков, вдруг вы знаете то что она не знает.
>по-старинке код в курсоре
Уже по старинке? Я наверное динозавр тогда. Пора вымирать..
Догоняй, дядя, нейронка сильно бустит продуктивность. Если опытный то будешь процентов на 30-40% эффективнее. Если нюфак то всё равно нужно освоить базу сначала, иначе не поймёшь когда нейронка будет тебе слоп подсовывать.
Лучше до переката расскажи про свою игру. Какая она будет?
Вселенная наоборот - это такая гипотетическая вселенная, в которой во время большого взрыва образовалась светлая материя (то есть тёмная материя наоборот). Светлая материя сначала была очень горячей, и заполняла всю вселенную бесконечным жидким океаном, затем она начала остывать, твердеть, превращаясь в бесконечный светлый кристалл, внутри кристалла образовывались пустоты. В этих-то пустотах и запустился процесс образования вторичной материи, атомов, молекул, синтез химических элементов... Аххх...
А? Что? Какая игра? Ну... Как Raft. Плывёшь сквозь Толщу на своём верном Толщеходе. Останавливаешься в пустотах. Фармишь минералы. Чинишься, апгрейдишься.
Я думал про такую игру, но проблема в геометрии землехода. Особенно если игра 2Д. Он будет только горизонтально двигаться? Если вниз вверх, то он должен переворачиваться на 90 градусов. Или он должен по наклонной с острым углом двитаться? Это трудно реализовать с точки зрения экспириенса персонажа в кабине.
Космические корабли имеют возможноть быстро маневрировать. Для толщехода это неправдоподобно.
С дирижаблями идея логичнее выглядит. Они могут вверх вниз двигаться не вращаясь. Но эта идея уже занята. Ты же не будешь у анона воровать..
>Этого вайба там нет
Потому что ты не попал в целевую аудиторию игры. Смирись уже с этим - эта игра не для тебя.
>какой-то мини корабль и плаваешь на нем (в нем дышишь и погружаешься)
Во-первых, далеко не сразу - сначала ты получаешь себе мелкий ускоритель, который не даёт тебе кислород, и у которого батарейку нужно менять. Он тебе нужен всю игру. Только потом ты получаешь круглый батискаф, у которого по умолчанию крайне слабые характеристики и без прокачки ты на нём далеко не уплывёшь - батареек не хватит. А ещё он супер-хрупкий. Да и в большинстве регионов легко заблудиться, потому что вода мутная и навигация по меткам очень неудобная. Подводная лодка ещё позже по геймплею, т.к. на неё нужно собрать кучу ресурсов, но пользы от неё действительно мало.
>ты двигаешься очень медленно, ты бьешься об стенки в кишке
Посмотрел бы я на тебя, как ты на реальной подводной лодке проплыл бы по подводной пещере, лол.
>Там есть мир - но нет геймплея зачем он весь нужен.
Ты просто не любишь играть в "open world surival craft" - этот жанр не для тебя.
>>ты с порога не разобрался в геймплее
>ты же видел базу, я собирал, строил
Вот-вот, не разобрался. На твоём скриншоте максимально унылая композиция из нескольких самых базовых прямоугольных коробок. Где хотя бы одна круглая секция? Где смотровая площадка со стеклянными стенками? Где второй этаж? Где лупоглазая станция дронов? Ты просто натыкал самых скучных прямоугольных коробок - непонятно вообще зачем - и обиделся на игру. Это как собрать прямоугольный небоскрёб из коричневых блоков в Minecraft и сказать "чёт скучно, мало контента".
Лично мне кажется, что базы в Subnautica избыточны в плане создания из мелких деталей. Меня бы полностью устроило развёртывание заранее заготовленной станции вместо создания каждый из таких отдельных мини-баз из кучи небольших деталей. Т.е. чтобы игрок не строил то, что вышло у тебя.
>Я поставил только мод на инвентарь, потому что скам
Потому что ты не разбираешься в механиках жанра "open world survival craft" - эта игра не для тебя.
>вроде игра заставляла плавать менять инструменты
>вообще не умножало иммерсивности исследования мира
Там у каждого инструмента батарейка. Это как, например, электродрель: пользуешься какое-то время от батарейки, батарейка разрядилась - вынул, вставил свежую - пользуешься, а старую батарейку можно поставить на док-станцию для подзарядки внутри базы, но в самом начале игры тебе приходится делать несколько батареек, т.к. док-станцию ещё создать нужно и запитать от внешнего источника энергии. Данные операции на 100% реалистичны и сильно играют на иммерсивность, т.к. в реальном мире автоматические инструменты действительно работают от батареек, которые приходится менять.
1. Стратегическая карта, толщеход перемещается как 2Д рпг - топ down.
2. Экран толщехода с комнатами и абгрейдами
3. Игровая локация игрока/игроков
Никто не понимает, как сделать игру во вселенной наоборот с Толщеходами. Поэтому её и не сделали.
>игроков
Я хотел сказать юнитов.
В теории можно объединить это oxygen not included
>А хотя нет, этот понимает.
Это Тодд Говард с заебашими всех в 2026 загрузками локаций. Тодд не понимает реалий современного игростроя..
>Вселенная наоборот
Ты всё ещё тот, кто пытался это делать, или просто решил потролить?
>>1069096
>Особенно если игра 2Д
Я ему предлагал сделать 2D сначала, но он упёрся, что игра должна быть 3D.
>Для толщехода это неправдоподобно
А "вселенная наоборот", которая выглядит как сыр маасдам - это правдоподобно?
>>1069097
>Но эта идея уже занята. Ты же не будешь у анона воровать...
Чем больше таких игр, тем лучше. Они всё равно все проваливаются в продажах.
>>1069102 >>1069106
У того анона-наоборот игра в жанре шутера/выживания с сюжетом, а не стратегия.
>>1069107
>Это Тодд Говард
Если не купишь скайрим, то шестые свитки будут на толщеходах
>загрузками локаций.
Просто не выгружай сцены. Браузер жрет гектарами, а мы 2д картинки большехода не можем в памяти держать?
Тут на самом деле проблема не в загрузках, а в том что апгрейд кабины и движение корабля в разных пространствах происходят и это трудно вместе связать. Корабль конечно можно достраивать в глобальном мире, но он будет все равно на капсулу похож базово. Трудно обяснить наглядно игроку что произошло при апгрейде с кораблем в большой локации. + Будет разделение на два разных геймплея. Что очень полохо, особенно для инди.
Из-за тебя мне теперь хочется заглянуть в Subnautica и освежить воспоминания... Наиграл, вроде, лишь 24 часа. Моя главная проблема с Subnautica была в том, что у неё кривая физика - лут постоянно падает под карту. Всё остальное в принципе терпимо. Да, карта мелкая, контента не так много, как в какой-нибудь GTA 5 Online - но для индюшатины очень даже неплохо, и выглядело это красиво даже на очень слабом ПК. Над шейдерами для воды точно поработали хорошо. Для сравнения, в той же GTA 5 Online есть возможность двигаться глубоко под водой на различном транспорте, включая батискафы, спортивные амфибии и советскую подводную лодку - но ощущается всё это максимально уныло и костыльно, как картонный спойлер на старых Жигулях. Они даже были вынуждены встроить телепортацию для подводной лодки, лишь бы игроку не приходилось использовать её вручную. Они пытались добавить в игру подводного геймплея типа "найди сундук сокровищ" (никчёмные $10.000-$25.000), но это всё СКУКОТА по сравнению с геймплеем той же Subnautica. Так что зря ты ругаешь её - это пример того, как инди нагибает АААА-корпорацию с миллиардами $$$.
Если делать толщеходы в 2D с видом сбоку, то не нужен никакой отдельный экран апгрейдов - просто зумишься в кабину и видишь все внутренности, зумишься из кабины - видишь общий план всего, что снаружи. Это очень легко реализовать на Godot, проблемы в этом никакой нет. Сам по себе толщеход должен быть похож на гусеницу или змею, но в этом тоже никакой особенной проблемы нет. Проблема только в том, что толщеанон хочет 3D экшон, суть такова: высаживаешься в круглую пустоту, а там на тебя монстры со всех сторон и ты можешь прыгнуть и прыжком добраться до противоположной стороны. Он тут уже об этом несколько раз жаловался, что стандартная игровая физика так не умеет и все плагины какие-то кривые или не нравятся ему чем-то.
Когда прорабатывал космо-приключалку пришел к такой идеи
двигатели и рулевая статичные экраны по бокам (скорее просто как ссылки), а в середине резиновое основание с комнатами и ты просто достраиваешь секции и в них комнаты.
Но нет более унылого чем космос. Дирижабли - гигадома где ты можешь сычивать и выращивать юпитерскую картошку - куда интереснее.
>Из-за тебя мне теперь хочется заглянуть в Subnautica и освежить воспоминания...
Это все из-за этого вайба:
>Смешно, но это похоже на симулятор какашки.
Стартовая атмосфера там годная.
Гринд и выживач в начале тоже годный
База шикарна
Даже тот корабль мотылек - шикарен
Начало сюжета с радио, который заставляет исследовать мир тоже шикарен
А дальше все пошло по кишке.
Хочет жить в этой базе, но в наполненном мире. Ну типа вот есть у тебя особняк в скайриме, но он вторичен, скайрим наполненный мир, где у тебя есть дом. А сабнавтика у тебя есть дом но мир пуст.
Сделали бы даже они какой-то монстер-хантер подводный - уже было бы ради чего строить базу (коллекционировать животных). Или еще что-то.
>Но нет более унылого чем космос.
Теоретически, строить космический корабль из мелких деталек интересно, но только при условии, что все эти детальки физически правдоподобны, но физика подкручена так, чтоб не слишком бесконечно улетало. Короче, игр про космос две крайности: ты либо строишь слишком реалистичную ракету и трясёшься за каждый болтик в нужной позиции, а потом разрываешься на части при попытке взлететь (KSP), либо плаваешь в "жидком вакууме", управляя чем-то вроде катамарана на озере (большинство космических игр). Если найти золотую середину сложности строительства и управления, то будет достаточно интересно.
А вот если высаживаться на планеты - то тут проблема в том, что в реальности большинство планет будут примерно одинаковыми безжизненными камнями, а если делать оживлённый фэнтези-космос с кучей независимых цивилизаций, то даже процедурно генерируем контент начнёт очень быстро повторяться. И иллюзия "бесконечного космоса" разваливается после десятка посещённых планет, например, в Starbound концептуально "бесконечное число миров", на практике - контента в Terraria побольше будет.
Кстати, в оригинальном Starbound примерно такой же концепт апгрейда космического корабля, как у тебя на рисунке - корабль как бы расширяется изнутри, раздвигая двигатели и пульт управления. Но мне и некоторым другим игрокам это не нравилось - слишком ограничивает для игры-песочницы, поэтому даже самом раннем доступе игры был мод на создание корабля из мелких кубиков - можно было оторваться по полной и сконструировать что угодно, от летающей каменной крепости до унитаза, т.к. геймплейно игра даже не проверяет наличие "двигателей" (огонька из сопла), которые там используются как чисто декоративные блоки. Там этот "корабль" - отдельная пустая локация с атмосферой. Я как-то тоже хотел сделать "Terraria, но в бесконечном космосе", и поэтому очень интересовался развитием Starbound - жаль, что в итоге он загнулся и умер.
>прыгнуть и прыжком добраться до противоположной стороны.
ну занизить физику до лунной гравитации не сложно, можно еще джеты добавить на спину.
>Он тут уже об этом несколько раз жаловался, что стандартная игровая физика так не умеет и все плагины какие-то кривые или не нравятся ему чем-то.
Скорее больше шанс что на деле это будет унылая фигня. Пока я понял - как только вырываешься из стандартного геймплея - ешь говна. Так что в реале лучше сделать бой по типу вампирик сурвайвал, но уже такая игра есть (под землей)
https://store.steampowered.com/app/2321470/Deep_Rock_Galactic_Survivor/
Когда я вдохновился простотой римворда и захотел свою игру по типу космо-рпг-адвенчуру, я узнал что автор римворда тоже начинал с подобной херни (и еще кто-то) и потом дропнул идею. И я почувствовал себя наивным. Типа такая чушь приходит в голову многим ньюфагам.
В реале космос скучен - ибо пустой. Если про планеты, то можно прям запариться и сделать их разными и даже интересными, но только зачем нам уже корабль, если вся движуха на планете, "спустись на землю" и строй базу там (как и сделал автор римки).
Только римка это симулятор преступлений с кучей модов. Повторить такое не сможешь. Да и кроме стройки там занять игрока нечем (автоматизацию интересно делать, смотреть как пешки тупят на х3 скорости - такое себе).
>Starbound
Не играл, просто хотел модульный корабль для постройки большого поселения (городка). Он даже не обязательно должен быть сигароподобным - мы же в космосе, можно как угодно.
>у тебя есть дом но мир пуст
Ты только что случайно любую игру жанра "выживание"...
>коллекционировать животных
Там вроде по сюжету нужно собрать образцы, чтобы найти противоядие от вируса.
>Или еще что-то.
Легко критиковать других, когда сам ничего по делу предложить не можешь...
Смысл "базы" игрока в выживалках - это место, где ты можешь укрыться от всех опасностей и спокойно поесть, подлечиться, починить экипировку, перезарядить пушки, инструменты и прочее. Иногда это мобильная база, которую ты возишь с собой по карте. Зачастую тебе приходится её защищать, но это всегда проще, чем вылазки наружу. А вылазки наружу нужны, чтобы восполнить ресурсы базы. Так и живёшь: посидел на базе - ресурсов мало, делаешь вылазку - налутал новых ресурсов, вернулся на базу - сидишь на базе, крафтишь шмот или ещё что-то. Это база жанра. Всё остальное можно наращивать сверху, но нужно ли?
Домик в скайриме бесполезен, потому что в скайриме ты можешь стоять спокойно в чистом поле и никто тебя не тронет, персонаж не проголодается, и ничего не сломается само по себе. Модами можно добавить голод, но в скайриме легко найти еду, т.к. там есть деревни и города. Поэтому, даже если бы там не было никакого контента кроме домика, домик там совершенно бесполезен - тебе не от кого прятаться, незачем закрываться в убежище и что-то крафтить.
>но уже такая игра есть (под землей)
В общем, без стандартной кор механики фантазировать смысла нет. Будь это даже трижды вывернутая вселенная, в основе должно быть что-то либо проверенное, либо гениально и не унылое.
>RimWorld
Там же есть моды для космоса. В ванильной игре ты просто строишь корабль и Game Over, а в моде это только начало - построил корабль, взлетел, и... ну, я не играл, только смотрел скриншоты. Вроде есть несколько похожих игр и модификаций к другим играм на ту же тему, так что тема довольно популярна.
>В реале космос скучен - ибо пустой.
Если у тебя корабль-колония, то ты постоянно занят его обслуживанием. Тебе не до космоса - ты пытаешься сохранить корабль и его экипаж, пока они добираются до следующей цели. А длину пути легко сократить классическим варп-двигателем, который переносит корабль из одной звёздной системы в другую. Остаётся только каким-то образом нагенерировать побольше разнообразных планет, где твоя колония добывает ресурсы.
>Да и кроме стройки там занять игрока нечем
???? Эм, ну, поиграй в Oxygen Not Included, например, если для тебя RimWorld "слишком простой и скучный" оказался...
>Легко критиковать других, когда сам ничего по делу предложить не можешь...
Ну охота на монстров - ради получения днк (прокачивать статы). Они кстати что-то хотели такое сделать.
Статы ты прокачиваешь чтобы попасть в новые локации, например выживание в холоде или тупо там будут данжи сильнее и тебе надо хп прокачать, так как больно бьют.
Или система исследований
Апгрейд базы. Например для исследования нужен какой-то модуль исследовательский.
А для него ферма юпитерской картошки.
А еще чтобы открыть n-исследование тебе нужна n-рыбка, а она в ядовитом биоме и нужно....
Создаешь цепочку действие-награда и все. За вечер можно тонны говна напридумать.
>Если у тебя корабль-колония, то ты постоянно занят его обслуживанием.
Да это понятно, тут просто если ты приземлишься на землю у тебя вариантов будет куда больше.
И фракции и торговля и данжи и нападания и животные и монстры и вообще лор планеты.
Типа сразу все вкуснее.
В общем, как только ты добавляешь интересную и не пустую планету, ты уже не хочешь летать. А процедурные планеты невероятно скучны (но ман скай, старфилд итд).
>прокачивать статы
>попасть в новые локации
>система исследований
>Апгрейд базы
Всё перечисленное - механики, оттягивающие конец игры, или как сказал этот анон - >>1069070
>скам... просто затягивание на ровном месте
Какая разница между тем, чтобы получить доступ к ледяному биому vs к ядовитому? В цвете мобов?
> шестые свитки будут на толщеходах
На Двемерских Толщеходах.
>>1069107
> Тодд не понимает
Он просто переборщил с загрузками.
>>1069108
> Ты всё ещё тот, кто пытался это делать, или просто решил потролить?
Тот кто пытался это делать, умер в 2012 году, 20 декабря, когда закончился календарь майя и произошёл коллапс ложного вакуума в наблюдаемой части нашей Вселенной (напрямик). Всё что ты наблюдаешь это бред твоего умирающего сознания. Именно поэтому с каждым годом наблюдаемая тобой реальность всё абсурднее.
>И фракции
Фракции космических пиратов, торгашей, борцов за добро.
>и торговля
Торговля с торговыми космическими станциями, кораблями.
>и данжи
Гигантские астероиды, заброшенные станции, места сражений.
>и нападания
Те же космические пираты, с фракцией которых ты всрал отношения.
>и животные
Космические киты, из которых некоторые расы делают био-корабли.
>и монстры
Космическая саранча, паразитирующая на китах и био-кораблях.
>и вообще лор планеты.
Если добавить побольше цивилизаций, то будет и лор.
И всё это уже придумано до нас и реализовано в разных играх.
>Домик в скайриме бесполезен,
В сабнавтике на тебя тоже никто не нападает.
А вот в скайриме есть ивенты нападение на особняк.
Для скайрима это место где ты разгружаешься, спишь для бафа/сохранения, крафтишь и выращиваешь для зельеварения. А еще дети, жена, играющий бард, охранник хускар и вообще ты его своими руками построил - это все иммерсивность.
При этом у тебя условно живой мир.
Скайрим тоже про моды и писоть-какоть-замерзнуть прикрутить там не сложно. Еду забалансить тоже можно (у меня есть удобная сборка, я на ней тестировал свои геймдизайнерские потуги). Там вообще можно собрать такое, что уже будет слабо напоминать ванилу.
И быть может на сабнавтику так было, если бы подарили людям более широкую игру.
>биому vs к ядовитому? В цвете мобов?
Любая игра это про цвет мобов и статы. Вопрос в том как ты это преподашь.
Лучше цветные мобы чем пустой мир.
Любую идею можно растянуть до абсурда.
Но за избыточность фантазии ты платишь иммерсивностью
Охота на кита в океане - будет иммерсивнее космического кита
Тоже с саранчой. Тоже с торговцами с караваном и вьючными животными.
Тоже поселение на земле где вокруг местность, животные, горы, пищера - это все иммерсивнее
Космос нам чужд.
https://store.steampowered.com/app/416240/Space_Impossible/
Если не ошибаюсь, это был Godot 3.5. По производительности вроде бы неплохо - с учётом того, что разрушение астероидов вызывает алгоритм flood fill на GDScript для проверки отделившихся частей, подсчитывает число блоков и выносит изолированные участки в отдельные RigidBody2D с отдельным TileMap, что было бы лучше вынести в модуль на C++ для полноценной игры. Удивительно, что это вообще так легко получилось сделать. Базовой задумкой было сохранить правдоподобную физику двигателей корабля - чтобы их число и расположение играло большую роль, и ещё сделать так, что игроку необходимо разворачиваться спиной вперёд и прицельно тормозить маршевым двигателем скафандра, а не как это в большинстве таких игр, где ты можешь просто отпустить кнопку и встать как вкопанный посреди пустоты. Но я потом почему-то потерял интерес к этой идее и забросил... Не помню, почему. Наверное, потому что для такой игры нужно создавать много уникального контента, а в конечном итоге вся игра получается на плоскости с видом сверху, что мне никогда в играх не нравилось - почему-то вид сбоку, как в Terraria, мне нравится больше, но в данном случае его никак не реализовать.
Второе видео вызвало больше ассоциаций с ледоколом (льдами).
>а в конечном итоге вся игра получается на плоскости с видом сверху
Не обязательно делать прям "сверху".
Можно всегда сделать подобие камеры под углом
https://2ch.su/gd/res/387381.html
Челики на 8 сторон залупились, демоны-незаконченных игр их и поглотили.
Если боевка ваш ключевой геймплей - не делайте её такой унылой.
Да ну в целом можно. Я согласен.
Если выкинуть поселение и сделать просто отряд наемников на корабле в сеттинге базы Xcom - блуждающий по миссиям/станциям - вообще будет классно и sci-fi.
>Тот кто пытался это делать, умер в 2012 году, 20 декабря,
Или откололся от этой версии вселенной и уже давно пилит третью часть игры. И люди вместо майнкрафта приводят пример с толщеходами, а девочки рисуют мемы вывернутой вселенной.
>> шестые свитки будут на толщеходах
>На Двемерских Толщеходах.
Это бы объяснило куда они пропали.
Умоляю, не показывайте это Тодду.
>растянуть до абсурда
В чём абсурд? Никогда не видел биокорабли? Было несколько sci-fi сериалов с разными биокораблями, а в книгах тем более. Самое хорошее - это когда твой гига-корабль... простите, твоя гига-кораблесса беременеет и рожает крутой и быстрый мини-кораблик, под который вы находите нового биопилота, сращиваете их и потом имеете в своём распоряжении сразу ДЖВА биокорабля - мать и дочь. Чисто гипотетически подобные биологические животные где-то в космосе вполне могут существовать, т.к. как минимум бактерии способны выживать в открытом вакууме, и если рыбы приспособились к давлению на дне океана - космос будет даже попроще. Единственный недостаток биокорабля для экипажа - это то, что ты живёшь в чьих-то кишках как бактерия в организме человека... И то, что эта громадина может заболеть космической простудой и сдохнуть. Или саранча сожрёт... Но биопанк в целом правдоподобен.
На счёт фракций, пиратов, торговцев, караванов и прочего в космосе - не вижу никакой проблемы, они почти в каждой игре есть. Если человечество размножилось до такой степени, что колонизировало каждую планету в галактике, а корабли собираются специальными автофабрикаторами из сырого железа и углерода, то пиратство точно будет. Если люди и их ИИ деградируют и утратят схемы для своих автофабрикаторов, то торговля между звёздными системами будет иметь смысл. Если есть торговли, то есть и караваны. Если есть пираты и торговцы - то наверняка будут и фракции, между которыми постоянная грызня за ограниченные ресурсы. Всё естественно.
>Но за избыточность фантазии ты платишь иммерсивностью
Ты совершенно не понимаешь термин "иммерсивность". Иммерсивность - это не "реалистичность" и никак не связана ни с графикой, ни с физикой, ни с лором игры. Иммерсивность есть даже у того же Тетриса, самого оригинального, из 1984, и у китайских подделок под Тетрис на дешёвом чёрно-белом дисплее, и у ньюфажеского Тетриса по туториалу тоже. Потому что механически Тетрис как игра ТРЕБУЕТ от тебя чёткого внимания, и если ты в него действительно хорошо играешь - ты "погружаешься" в него, то есть твой ментальный фокус срастается с этим клеточным стаканом и фигурками на экране, ты перестаёшь замечать окружающий мир и думаешь только о том, как уложить очередную фигурку в стакан. Другие слова, похожие по смыслу феномена на "погружение"/"иммерсию" - это "транс" и "поток". Т.е. "погружение" - это "состояние сильной сфокусированности на игре". Как достичь этого состояния? Уж точно не "реализмом" графики, физики и лора. Как минимум нужно, чтобы игра требовала от тебя фокусироваться на игре, например, непрерывно угрожая Game Over'ом.
Поэтому данное твоё утверждение категорически неверно:
>Охота на кита в океане - будет иммерсивнее космического кита
Иммерсивность данных действий будет зависеть исключительно от механической реализации и при прочих равных она будет абсолютно равной. По сути это может быть одна и та же механика с заменёнными моделями, текстурами и шейдерами. И большинство "космических игр" страдают именно от того, что они по сути натягивают "космические" текстурки на геймплей "морской" игры с её замедленным движением и торможением об воду - отсюда пошло выражение "жидкий вакуум" и ему подобные. По-настоящему космическая игра требует топливо на ускорение и торможение, но не на полёт, потому что тормозить в космосе можно только путём отталкивания от продуктов сгорания топлива или чего-то похожего, если мы рассматриваем более-менее современные двигатели. Но это всё не касается иммерсивности игры в целом - то есть даже "морские игры с космическими текстурами" могут быть иммерсивны, несмотря на полное нарушение физики космоса.
>>1069145
>Второе видео вызвало больше ассоциаций с ледоколом (льдами).
Из-за текстур, скорее всего. Там использован лазер для ускорения процесса (в оригинальной игре ты очень медленно прогрызаешь такие астероиды, приходится буквально обвесить корабль лазерами, чтобы сверлить астероид быстрее).
>Можно всегда сделать подобие камеры под углом
Для персонажа - допустим, но корабль вращается на все честные 360 градусов, поэтому его стенки могут быть только "вид сверху", как в том же RimWorld, а это выглядит очень уныло на мой взгляд. Но вращение игромеханически - самый кайф.
ты будешь перекатывать?
https://godotengine.org/article/release-candidate-godot-4-6-rc-1/
>>1069165 (OP)
>>1069165 (OP)
>>1069165 (OP)