Шапка: https://hipolink.me/godothread
Предыдущий: >>1026834 (OP)
Архивный: >>1022039 (OP)
Сделай тетрис. Сделай его ещё раз.
Хотелось что-то более интересное, из простых игр я делал шарики на рейлибе с поиском пути
Я симулятор своей жизни делаю. Воссоздал квартиру, город, соседей, все такое. Симулятор медленного гниения в нищете в хрущевке, тлен и безысходность, путь к единственной концовке.
Главное, если зайдёшь в игре в свою квартиру, и увидишь как ты сам сидишь играешь в свою игру, то ни в коем случае не подходи к себе в игре.
Платформа:
extends CharacterBody2D
class_name Player
const SPEED: float = 350.0
func _physics_process(_delta: float) -> void:
var direction: float = Input.get_axis("ui_left", "ui_right")
if direction:
velocity.x = direction SPEED
else:
velocity.x = move_toward(velocity.x, 0, SPEED)
move_and_slide()
Шарик:
extends CharacterBody2D
class_name Ball
const SPEED: float = 300.0
var moving_vector: Vector2 = Vector2.DOWN
func _physics_process(_delta: float) -> void:
velocity = moving_vector SPEED
if move_and_slide():
var collision: KinematicCollision2D = get_last_slide_collision()
var object: Object = collision.get_collider()
if object is Node:
var _node: Node = object
if _node.name == "Blocks":
assert(_node is TileMapLayer)
var blocks: TileMapLayer = _node
#print(collision.get_position())
var colliding_cell: Vector2i = blocks.local_to_map( collision.get_position() + moving_vector )
#print(colliding_cell)
blocks.erase_cell(colliding_cell)
pass
var angles: Array[float] = [-1.0, 1.0]
var random_angle_deg: float = angles.pick_random()
var random_angle_rad: float = deg_to_rad( random_angle_deg )
moving_vector = moving_vector.bounce(collision.get_normal().rotated(random_angle_rad))
Спасибо. А то тред захватили архитекторы душные. Не осталось места простым одноклеточным уебкам.
Ну можем обсудить, я особо не думал, что первое пришло в голову то и сделал. Проблема была только с collision.get_position() + moving_vector, если не добавлять эту писечку то тайлмап ебаный округляет до ячейки в которой шарик
Каждый блок при коллизии с чем угодно (в данном случае) просто делает роскомнадзор. Мячик же в свою очередь умеет только отскакивать.
Можно было и так, но пришлось бы блок делать отдельной сценой и, либо руками расставлять ровно все блоки, либо подгонять чтобы в TileMapLayer она была ровной, а там какое-то несоответствие было, я один раз делал такое и приходилось подбирать позицию картинци в сцене
Во-первых, я бы рекомендовал использовать это:
https://docs.godotengine.org/en/stable/classes/class_physicsbody2d.html#class-physicsbody2d-method-move-and-collide
Потому что move_and_slide() производит много чего абсолютно лишнего для твоего шарика (да и самой платформы), а move_and_collide() сразу возвращает случившееся столкновение, если оно случилось. Но необходимо умножать вектор движения на delta.
Во-вторых, я бы создавал блоки как независимые физические объекты, а не как ячейки тайлмапа, т.к. продвинутые арканоиды навешивают много разных спецэффектов и способностей на блоки. Тайлмап тут чрезмерно ограничивает и при этом избыточен - он предназначен для больших статичных ландшафтов.
Небольшие замечания:
- после "if object is Class" редактор скриптов должен автоматически подставлять нужные поля класса, т.е. присваивать объект к новой переменной не нужно;
- если нужно сравнивать строки, лучше объявить константу с типом StringName и сравнивать с ней;
- class_name должен находиться перед extends, чтоб совпадать с порядком записи внутренних классов.
>>1030933
>руками расставлять ровно все блоки
Уровни в арканоидах легко генерировать процедурно.
>Потому что move_and_slide() производит много чего абсолютно лишнего
Можно, но я об оптимизация не думал даже
>>1030935
>т.к. продвинутые арканоиды навешивают много разных спецэффектов и способностей на блоки
Не вижу пока проблемы, если приведёшь пример, возможно соглашусь, даже если там какое-нибудь ебанутое переливание света то его можно наложить на блок отдельно
>>1030935
>- после "if object is Class" редактор скриптов должен автоматически подставлять нужные поля класса
Вот это не знал, спасибо
>>1030935
>если нужно сравнивать строки, лучше объявить константу с типом StringName и сравнивать с ней;
Ну это из разряда микрооптимизаций, там сравнение по имени просто по приколу
>>1030935
>class_name должен находиться перед extends
Этот устой я ломаю, мне так логичнее и удобнее чем дописывать перед extends
>>1030935
>Уровни в арканоидах легко генерировать процедурно.
Это был просто арканоид за ~полтора часа из которых 15 минут я срал, 10 минут разбирался с неверно определяемой ячейкой тайлмапа, 2 минуты рисовал блоки в асепрайт, 10 минут переделывал коллизии(т.к. потолок и стены сначала были как WorldBoundaryShape и только при запуске годо сказал что ему не нравится их пересечение и пришлось менять на прямоугольники), он мне не интересен как игра, просто анон предложил сделать
Кстати в гугл плее это вполне себе удачная ниша. Только там арканоиды доведены до крайности, вида "шарики множатся х500, а до ломаемых блоков ты добираешься через туннель в 1 пиксель".
Думаю, любая игра с примитивным геймплеем, которую в любой момент можно открыть, поиграть и закрыть, будет удачной для портабл устройств, в том числе и телефона - 2048, судоку туда же.
> Тайлмап тут чрезмерно ограничивает и при этом избыточен - он предназначен для больших статичных ландшафтов.
В чётвёрке в тайлмап добавили возможность сцены как тайлы устанавливать, то есть, представь себе, блоки в тайлмапе это отдельные объекты со спрайтом, телом, областями, частицами, и этим блокам можно прописать любую тряску, какую пожелаешь.
>оптимизация
Это не оптимизация, у тебя шарик будет СКОЛЬЗИТЬ. Функция move_and_slide() по умолчанию делает до 4 отскоков, прежде чем вернуть контроль твоему коду.
>можно наложить на блок отдельно
С тайлмапом это не так удобно, как со сценами. Этот тайлмап выглядит преждевременной оптимизацией.
>мне так логичнее и удобнее
Чем логичнее? Обычно читается так:
>класс по имени Игрок расширяет CharacterBody2D
Наоборот получается нелогично:
>расширяет CharacterBody2D класс по имени Игрок
У нас Йода магистр что ли ты?
>2 минуты рисовал блоки в асепрайт
Вот главная ошибка. Нужно юзать icon.png с Godot.
Интересно, не знал. Не пользуюсь ими вообще. И как, насколько удобно добавлять сцены в тайлы? GridMap позволяет сгенерировать блоки из сцены, но это очень неудобно, по крайней мере как я это помню (давно уже забросил из-за ограниченности GridMap).
>Это не оптимизация, у тебя шарик будет СКОЛЬЗИТЬ. Функция move_and_slide() по умолчанию делает до 4 отскоков, прежде чем вернуть контроль твоему коду.
Ой всё
>С тайлмапом это не так удобно, как со сценами. Этот тайлмап выглядит преждевременной оптимизацией.
А мне удобно мышкой делать сразу линию блок блоков, паттерны можно сохранять.
>Чем логичнее?
Тем, что годо генерирует первую строку extends и она определяет к какой ноде прикреплен скрипт, и если поменять тип ноды я буду менять первую строчку, она основная, а class_name это просто алиас, не нужно мне это навязывать, я видел это в документации в рекомендации к оформлению кода, но у меня это не укладывается в логическую цепочку потому что она не класс->базовый класс, а класс ноды->базовый класс->алиас
>>1030958
>Нужно юзать icon.png с Godot.
Да, проебался.
Недавно смотрел джем один, с довольно серьёзным призом, ведуший не знает про годо ничё, а в игре ГГ - иконка ебаная и он такой спрашивает "Мы что играем за голову робота в банке?"
Ну так же удобно как и любые тайлы. Вместо ссылок на текстуры в тайлсете ссылки на сцены. Инстанцирование/высвобождение идёт прозрачно под капотом, ты просто индексы меняешь в коде, а тайлы уже сами за себя отвечают.
>она определяет к какой ноде прикреплен скрипт
Не обязательно, Godot за этим не следит (лол).
>если поменять тип ноды я буду менять
Не обязательно, можно забить в 99% случаев.
>class_name это просто алиас
Это имя заменяет имя файла, сравни:
>extends "player.gd"
>extends Player
Семантически это одно и то же.
Использовать это имя ты, по идее, будешь чаще, чем строчку с классом-предком. Ибо class_name вовсе не обязателен и его лучше не писать, если твой скрипт объявляет что-то локальное и малозначимое. Т.е. не засоряй поле видимости классов лишними именами; нужные имена пиши на самом видном месте.
Приведу пример. Ты делаешь класс:
>class_name Ball extends RigidBody2D
>func _init(size: float) -> void:
>func bounce() -> void:
Теперь ты можешь делать так, например:
>var ball: Ball = Ball.new(5)
>if node is Ball: (node as Ball).bounce()
>for ball: Ball in get_children(): ball.bounce()
И т.д. Если тебе это не нужно - забей на class_name.
>Не обязательно, можно забить в 99% случаев.
Чел
С таким траем нашлась неожиданная тупость - детект коллизии на стороне блока практически мертвый номер, только раздутая поверх коллайдера Area2D (именно больше самого коллайдера) срабатывает. Костыльно короче, хотя думал так будет логичнее и лучше, а получилось как всегда. Похер, первый раз на годоте пишу, попробую проапать этот "арканоид". Вектора отскока не рандомными чтоли сделаю, процедурную генерацию, счет какой-нибудь и тд, хз. Потом видеоуроки от школьника гляну чтоли.
Можно прикрепить скрипт Node на любую ноду. Ты обычно меняешь ноду на что-то более специальное, изначально выбрав что-то более обобщённое: брал, например, Node, а потом решил добавить смещение, поменял на Node2D или Node3D, а код не исправил.
Это баг и о нём знают, но его не решаются фиксить, потому что некоторые научились его использовать в качестве хака для двойного наследования, поэтому исправлять будут только после добавления Traits.
>>1030975
>детект коллизии на стороне блока
Можно так, на стороне мячика:
>if "hit" in collider: collider.hit()
>else: # ударились в стену, например
Называется "duck typing": "если крякает, крякаем".
Как бы да, но можно и сам блок сделать Area2D
>>1030977
Я так захотел. Я могу всё сделать на Area2D двигая мячик через изменение позиции и это будет работать, а могу подключить Box2D, наверняка есть расширение и сделать там, зачем спрашивать такие вопросы?!
>>1030979
>Можно прикрепить скрипт Node на любую ноду
Да, и только так и можно, скрипт "родителя" можно вешать на "наследника". Я обычно меню чарактер на арею или ригид и такой фокус не получается в 99% случаев, это не баг это просто ООП
> будут только после добавления Traits.
Мммм... Трейты в гдскрипте. Ух, заживём.
https://github.com/Earewien/godot-traits
>меняю чарактер на арею или ригид
И часто приходится это делать?
Чаще всего Control ноды меняю, но там как раз чаще получается замена родителя на одного из потомков.
>>1030986
Это какая-то неофициальная васянка?
Трейты сам Хуан предлагает, вроде бы. Как замену множественного наследования.
># We can now damage the crate >GTraits.as_damageable(crate).take_damage(10)
Какой-то лишний геморрой...
Предложение Хуана будет работать просто:
>crate.take_damage(10)
>Я могу всё сделать на Area2D двигая мячик через изменение позиции и это будет работать
А вот не факт, там насколько помню если просто менять позицию то будут глюки, поскольку физ движок будет ее перезаписывать своими рассчетами. И правильно двигать через PhysicsDirectBodyState с PhysicsServer2D.BodyState.BODY_STATE_TRANSFORM
https://www.reddit.com/r/godot/comments/1fjuzdg/code_to_teleport_rigidbody2d/
Например в документации прямо сказано
RigidBody2D ... It cannot be controlled directly, instead, you must apply forces to it (gravity, impulses, etc.), and the physics simulation will calculate
If you need to directly affect the body, prefer _integrate_forces() as it allows you to directly access the physics state.
Кто то писал что он перед движением делает body.set_physics_process(false) но у меня есть сомнения что это будет всегда работать в правильном порядке.
Оформление через emoji = высокая вероятность генережки от ИИ...
Ты чет из моды выпал. Свистопердящие проекты так оформлялись еще когда нейронки под стол пешком ходили всратых собак генерили.
>А вот не факт
Факт. В 3д с арией делал и детектилось. Конечно если ты позицию только не изменишь настолько, что объект "пролетит" свозь коллизию, это называется вроде гхостинг
У ригид боди своя отдельная история, ему в принципе нельзя задавать позицию после того как он уже существует, хотя он так же подвержен этому эффекту и для этого ввели параметр с пика
Звучит так что банально повезло. У игрока на компе будет другой фреймрейт и все.
Так и отлично же. Не отвлекает, а значит наконец то пришло время делать свой клон игрули в которую постоянно залипал там. Лучше же залипать в своей реализации в годоте.
Я тестовую сцену накидал, Area2D - детектор и Area2D - "пуля", пуля постоянно спавнится с увеличением скорости, начиная с 1000, движение происходит примерно по формуле position.x = position.x + speed * delta и был вариант с move_toward в общем то результат одинаковый для любой формулы и process/physics_process - при достижении скорости в 2700 детект не происходит т.к. начинается гостинг.
Далее вместо пули - CharacterBody2D и движением:
velocity.x = speed
move_and_slide()
Тут даёт 2900 и опять гхостинг.
Это для дефолтных коллизий круга и прямоугольника. В принципе терпимо для многих ситуаций, не о прецижион платформере же речь
RigidBody можно менять позицию, но:
- это вызывает какие-то перерасчёты (дорого);
- это сбрасывает симуляцию движения (глупо);
- это может вызвать нежелательный телепорт.
Поэтому рекомендуют не трогать их Transform.
Если вам ригид нужно телепортировать - ОК.
>>1031024
Если хочешь быстро и без перескоков - RayCast.
Если лазерной точки недостаточно - ShapeCast.
mOdErN_gAmE_dEvElOpMeNt.png
>RigidBody можно менять позицию, но
Записать ты можешь, но физическому движку на это всё равно, в момент появления рида в сцене его трансформация копируется в физ. движок и обновляется оттуда с большой скоростью, один вариант если ригид "уснёт", ты можешь обновить позицию, но "разбудив" его позиция опять обновится из физ. движка. Если не будить визуально онг "телепортируется" но ты с этим ничего не сделаешь.
Давай, покажи, как ты будешь двумя ифами всё проверять иногда(не в каждом фрейме). Научи нас о великий мыслитель
Не занимайся преждевременными оптимизациями. Если это речь про один единственный объект управляемый игроком - вообще пофиг, там можно на это хоть миллион тактов процессора отложить. Ведь представь там мог быть не шарик, а целый tps контроллер с целыми деревьями анимаций и скелетами костей и все это успевает работать.
>Если не будить
А ты буди его, в чём проблема?
Хорошо, ладно, вот задача:
1. Игрок на VehicleBody заехал в круг телепорта.
2. Телепорт выплюнет игрока за 1 км от входа.
3. Машина остаётся с игроком без изменений.
Предлагаешь queue_free() и новый автомобиль?
А если там много кастомизаций, повреждений?
Так вот из-за кого в новых играх долгие загрузки...
Дебич, тебе расписать два ифа, где Х и Y больше равно / меньше равно нужного значения? Твоё ебало просто в рамку и в музей компьютерных игр с подписью "да, вот дебилы-вайбкодеры вроде него разрушили индустрию".
ТЫ же понимаешь, что по такому принципу написано 90% сегодняшней индюшатины у стиме? Они в основном все не на годоте правда, а на юнити, но это только потому что нормисы все в юнити текут в основном.
>нужного значения
Откуда значения будешь извлекать?
Просто интересно, будешь все блоки перебирать?
>>1031044
Он же сказал, что он это за 15 минут сделал:
>>1030938
>15 минут я срал
>Откуда значения будешь извлекать?
Из геометрии балок, которую ты сам до этого изобрёл.
>А ты буди его, в чём проблема?
Бля ты бы сам пошёл попробовал, прежде чем хуйню нести про в чём проблема
Ладно, просто меня в детстве пиздили томиком Страуструпа по голове, не обижайся.
>>1030997
>>1030995
Ваще трейты (типажи) это разновидность интерфейсов, даже лучшее название чем интерфейс, потому что интерфейс в изначальном смысле это все публичные члены класса/объекта/сущности, называть интерфейсом отдельную сущность было ИМХО ошибкой.
В годоте почти придумали годную замену трейтам/интерфейсам - группы. Достаточно было заложить в гдскрипт механизм валидации вхождения в группу. То есть еще с трёшки есть методы типа call_group() там юзается утиная типизация, если член группы может крякнуть, на нём вызывается кряк, и идёт дальше. Достаточно было в этот механизм добавить строгий режим, чтобы в определение группы можно было вписать метод кряк, и чтобы попытка добавления в группу требовала явно реализовать метод кряк. Ну и всё. Получаем трейты/интрфейсы. Да ещё и с поддержкой в инспекторе.
>>1030997
> Предложение Хуана будет работать просто:
Ну ладно. И так сойдёт.
Дружок-пирожок, а ты знаешь сложность твоего сравнения ифами? Она нахуй квадратичная, потому что придется делать ифы всех ко всем. А вот физический движок использует тонну способов оптимизировать это говно, и там сложность логарифмическая, потому что используются пространственные структуры данных для быстрого поиска соседних точек. Более того, в 4 рапира на с++(или раст, не помню уже), а гдс имеет минимальный оверхед на доступ к движковым функциям, что баш на баш даст приемлемую производительность, которая будет гораздо лучше твоих ифов при любом раскладе.
Звучит как что-то не очень сложное что ты можешь сделать аддоном как Proof of Concept.
Хмм... Хмм.... Подумоем.
Ну а я буду иф-елс-ретурн. Оптимизация, шах и мат, и ретурн.
>Более того, в 4 рапира на с++(или раст, не помню уже), а гдс имеет минимальный оверхед на доступ к движковым функциям, что баш на баш даст приемлемую производительность, которая будет гораздо лучше твоих ифов при любом раскладе.
Жопу ставишь? А то я raylib стартану и накатаю пару строк, если на кону твоя жопа.
Ты даже на гдскрипт не смог пару строк накатать, куда тебе языки взрослых людей
То что твои гдс ифы будут медленее физдвижка? Ясен хуй ставлю.
Ребят, вы чего? Какие ифы всех со всеми в арканоиде? Повторю: это игра на гриде. Там все высчитывается через mod % от x, y и смотрится в массивчике.
А по поводу raylib - скажем так, годот вполне может физически из-за недостатков собственного движкового апи не потянуть тот уровень, при котором кривая сложности расчетов обойдет твою наивную реализацию на чистой сишке без всего оверхеда апи движка. Лучше сравнивай анрил/unity il2cpp с raylib, ручаться не стану, но чисто математически и изза лучше проработанного апи - может результат будет лучше.
Ты так позицию мяча просто конвертируешь в ячейку тайлмапы, буквально blocks.local_to_map(collision.get_position()) из кода, в твоём случае будет только ball.position, каждый кадр будешь проверять? и это будет не верно, нужно проверять пересечение круга и прямоугольника.
Скоро фантазёры начнут предлагать вместо использования камеры сдвигать позиции всех объектов относительно игрока.
>как найти пересечение круга и грида
Сорян, не понял сразу что ты вайбкодер
В целом кстати, я подумал, если кешировать точку прошлой коллизии, а затем при новой проверке в случае ненахождения внутри заданной точки применять метрику чебышева + вектор направления в матрице квадартов, при условии что обьекты не будут телепортироваться, тогда сложность будет o(n) в самом худшем случае (поиск первой коллизии) а в самом лучшем - нам понадобится проверить всего 3 соседа, в чуть худшем - 5 соседей. Но обычно только 3. По идее такой алгоритм будет намного быстрее поиска в пространственной структуре, но он очень не любит телепортации. Надо будет опробовать, спасибо анончики за идею.
>Скоро фантазёры начнут предлагать вместо использования камеры сдвигать позиции всех объектов относительно игрока.
Могу сказать что это реально работает. Размер сетки из квадратов для коллизий можно очень сильно ужать благодаря такой хитрости. Сдвигать их непосредственно может и не надо (хз о чем ты), но вот конвертировать в пространство игрока стоит, операция копеешная. Тогда игрок будет всегда в центре колизионной сетки, а колизионные обьекты - всегда вокруг него, максимально выжимая небольшой обьем сетки в работу.
> самом лучшем - нам понадобится проверить всего 3 соседа, в чуть худшем - 5 соседей. Но обычно только 3
Похоже на правду. ЕМНИП кармаковский рейкастинг в Wolfenstein 3D работал. Там же чисто аналитически можно узнать на пути линии движения в каких точках пересечения со стенками клеток.
З.ы. а для тех кто будет говорить "ну там же круг!!1" - так в квейке БОКС коллайдер заменен точкой, а толщина стен увеличена на нужное значение. С круглым коллайдером все еще проще будет.
Никто не предлагал BSP деревья, не пизди.
>Один предлогает делать проверку коллизий круга и квадрата самостоятельно вместо годота, который её делает и так
Он не делает "и так", он использует физический движок, что оверкилл по сравнению с простой аналитической формулой линий.
Это буквально как нанимать целый железнодорожный состав чтобы перевезти 1 пакетик доширака.
>что оверкилл
Понятно, тред позёров фанатазёров, которые не представляют как работает физический движок, лучше на форуме годота сидеть
Боюсь представить конечный размер экзешника и библиотек с оверхедами.
>подрубать целый движок годот когда можно использовать рейлиб или сдл
Боюсь представить конечный размер экзешника и библиотек с оверхедами.
>что оверкилл
Для арканоида сам годот оверкил. О том и говори сразу, не хочется годот, хочется свой велик писать. 100% понимания, но тред не об этом.
От годота в первую очередь нужен рендер и шейдеры. Потому что вот это заебешься писать. А вот игровая логика физику вовсе не обязана использовать.
>Использовать ЭВМ вместо спичечных коробков и скомканной фольги в картонной обувной коробке
Зарплату родителей этих мажоров представляете?
Допустим, у нас есть такой компонент:
>class_name Health extends Node
>signal changed()
>@export var value: float = 100
>@export var value_max: float = 100
>func take_damage(value: float) -> void:
Композиция - когда объект владеет другим объектом, живущим ровно столько, сколько живёт его владелец. Следовательно, на GDScript мы можем сделать так:
>class_name Enemy extends CharacterBody2D
>@onready var health := $Health as Health
Если мы хотим обратиться к нему, мы просто:
>func give_damage(node: Node) -> void:
>_ if node is Enemy: node.health.take_damage(value)
Либо, если у нас несколько таких классов:
>_ if "health" in node: node.health.take_damage(value)
Это будет работать, ибо мы гарантируем наличие компонента heath всю жизнь конкретного Enemy. В ситуации, когда нода health вдруг пропала, сцена сломается и движок должен выдать ошибку.
Агрегация - когда объект может иметь ссылку на независимый другой объект; объекты могут быть созданы и удалены отдельно друг от друга. В Godot примером является дерево сцены - добавление нод другим нодам равно агрегации по умолчанию. Тогда реализовать доступ к компоненту можно так:
>func give_damage(node: Node) -> void:
>_ var health := node.get_node_or_null("Health") as Health
>_ if health: health.take_damage(value)
Если нода не имеет ноду "Health" в потомках или она неподходящего класса, то "health" будет равно null и последняя строчка просто не выполнится. Можно реализовать неуязвимость, удалив ноду "Health".
Собственно, вопрос: чем "фреймворки" могут быть эффективнее этих стандартных подходов Godot?
Я вообще мимопроходил, у меня смежная задача но просто умник со своими ифами стриггерил. Кстати квады вроде никто не предлагал, предлагали просто дробить пространство на обычную матрицу и по ней шароебиться.
>>1031112
Напротив, мы отлично знаем как работает физдвижок. Проблема в том что в годоте в отличии от условного беви вызов физдвижка сам по себе очень нетривиален, и только этими накладными расходами можно умножить на ноль все плюсы от его применения, и может так статься что будет лучше велосипедить.
Отвечает Александр Друзь: В Годоте есть всё что нужно чтобы сделать игру, никакие дополнительные фреймворки не нужны. Все недостающие тебе инструменты ты можешь легко скомпоновать из имеющихся инструментов редактора Годот (как ты и показал в своём посте). Так что ты прав, никаких фреймворков не нужно. Продолжай делать игры.
Покажешь где в треде упоминаются фреймоврки для композиции? Или ты про трейты? Трейтам нужна поддержка в языке, да.
>указать nodepath до ноды в другой сохраненной на диске сцене
Это ведь будет работать только если сцены корректно загрузятся?
>но все же можно. Не знаю зачем, но можно
Потому что твой Блокнот не проверяет корректность путей в tscn?
Я помню, как приходилось править пути в AnimationPlayer через Блокнот, потому что я как-то не так переместил какую-то ноду и все пути поломались, и Godot не мог их восстановить, ссылаясь на какую-то больше не существующую или перемещённую ноду. Пришлось открыть tscn в Блокноте и вручную пофиксить эти пути - всё заработало.
Для такого фикса править tscn вручную приемлемо, в остальных случаях не рекомендую даже заглядывать туда, потому что всё это генерируется редактором и перезаписывается, поэтому ручные правки скорее всего исчезнут при следующем сохранении сцены.
>Это ведь будет работать только если сцены корректно загрузятся?
Ага. На самом деле я это обнаружил сохранив группу нод по ПКМ -> save branch as scene, и у одной из сохраненных нод был нодпас указан на ноду, не попавшую в сохраненную группу.
>в остальных случаях не рекомендую даже заглядывать туда
Хорошо, мам, я перестану заглядывать годот-тян под юбку. Нет.
Аддон, который мы все тайно жаждали, но боялись попросить:
https://store-beta.godotengine.org/asset/joyless/you-can-do-it/
https://godotengine.org/asset-library/asset/3267
>Anime girls motivate you every 15-30 minutes.
>Features:
>- Girls holding programming books
>- Nice girls to compliment you
>- Chill girls to greet you
>- Mean girls to insult you
>- Collect girls in the catalog
Based & gachapilled.
Зачем делать игры, если можно играть в Godot?
>у одной из сохраненных нод был нодпас указан на ноду, не попавшую в сохраненную группу.
Тогда это баг редактора, потому что такого быть не должно. Сцена из-за этого может ломаться.
Я не помню, сталкивался с этим или нет, но 100% видел сломанные ссылки на "чужие" ноды...
Алсо 4пик моделька червяка из конца игры, лепил его, лепил, а в получился хуй, лол, но в игре это сложно заметить.
https://rouw-x.itch.io/deserted
https://github.com/cariad/gdscript-typed-performance
Это называется бенчмарк.
Не забывай, что в нем обычно происходит только одно какое то вычисление массово.
Игра состоит не только из одного этого момента, поэтому может быть суммарный прирост будет всего процентов 5.
База. Похоже на DUSK.
Небо красивое. Это статичная картинка или что-то посложнее?
Спасибо
>Небо красивое. Это статичная картинка или что-то посложнее?
Самая обычная hdr-ка
>доквы что он работает на 30-50% быстрее?
Бенчмарк тебе уже скинули, хотя мог бы и сам его реализовать всего за пару-тройку минут, например:
>var start_time := Time.get_ticks_usec()
>var a = 0
>for i in range(10_000_000): a += 1
>print("untyped: ", Time.get_ticks_usec() - start_time)
>start_time = Time.get_ticks_usec()
>var b := 0
>for i in range(10_000_000): b += 1
>print("typed: ", Time.get_ticks_usec() - start_time)
Этого должно быть достаточно.
Если хочешь теоретическое обоснование ускорения: нетипизированные переменные - это данные плюс ID, обозначающий тип данных. Зачем нужен ID? Чтобы компьютер знал, что с этими данными делать. Если требуется операция с данными, компьютер сначала проверяет ID, и только потом производит операцию, соответствующую обозначенному типу данных. Т.е. типизация скрывается от программиста, но от неё невозможно избавиться полностью. Компьютер (компилятор или интерпретатор) берёт на себя ответственность за проверку типов вместо тебя.
Когда ты явно обьявляешь типы, ты хранишь только конкретные данные, которые передаются заранее обозначенным операциям. Компьютеру больше нет необходимости проверять тип, потому что ты задал конкретную операцию с данными явным образом. Соответственно, выполнение кода ускоряется - т.к. избавляемся от лишних скрытых от глаз проверок.
Наглядный пример:
>func sum(a, b): return a + b
Оператор "+" может принимать int, float, string, Vector2, Vector2, и, возможно, другие типы. Что должно будет произойти после вызова sum? Несколько примеров:
>print(sum(1, 2)) # 3
>print(sum(1.5, 2)) # 3.5
>print(sum("1", "2")) # "12"
>print(sum(Vector2.ONE, Vector2.ONE)) # Vector2(2, 2)
Чтобы это всё работало, компьютер должен скрытно произвести операцию сравнения, подобную такой:
>match data_type:
>_ TYPE_INT: ... # целочисленное сложение
>_ TYPE_STR: ... # конкатенация строк
И т.д. Очевидно, эти операции тратят какое-то время.
Если мы пишем наш код так:
>func sum(a: int, b: int) -> int: return a + b
То компьютеру больше не нужно угадывать значение операции "+", он просто выполняет целочисленное сложение в любом случае. Естественно, это быстрее.
Конкретную реализацию в GDScript я не видел, и всё объяснение чисто на моей интуиции и опыте разных языков программирования. Могу ошибаться.
Ещё интереснее с типизацией Array: чтобы Array мог принимать любые данные, вместо самих данных там сохраняется ссылка на адрес в памяти. Т.е. сначала необходимо перейти по ссылке, проверить тип, и уже потом выполнить запрошенную операцию. Поэтому "обычные" массивы (Array) в GDScript почти такие же медленные, как и Dictionary (ассоциативный массив). Зачастую выгоднее использовать Dictionary вместо динамического массива с произвольными данными.
>что потом?
Зачем в геймдев вкатился?
Начинай делать свою игру мечты.
Или что-то, что может принести деньги.
Или ищи вакансии джуна на Godot (удачи).
А никто и не шутил.
Нужно пропускать через себя и думать что именно делаешь, и почему так. А не просто переписывать.
Годот вообще может деньги принести?
Или только на Юнити возможно, где индустрия огромная итд?
Смогу ли я хотя б 80 тысяч в месяц поднимать в Годоте стабильно и не сдохнуть с голоду или опять дворником работать идти и продолжать бухать и курить?
>Посоны (ничего, что я вас так называю?)
Литералли пикрил, лол.
>Смогу ли я хотя б 80 тысяч в месяц поднимать
Геймдев не про деньги, геймдев - про игры...
>>1031330
У фальки бизнес и пенсия, зачем ему работать?
>>1031327
>А никто и не шутил.
Нужно сразу нормально писать, а не шутить.
Игры могут принести деньги. Не движок. Движок уже приносит деньги Хуану и сотоварищам. Так что делаешь игры и пытаешься их продавать. Если ты умеешь делать интересные игры, ты обязательно заработаешь. Но вообще да, проще вернуться в дворники, так стабильней.
Где бесплатные курсы посмотреть, как сделать платные курсы по производству игр на Годоте?
Оплачиваемого геймдева не существует, это наеб для гоев. Либо влетаешь по знакомству, либо пилишь киллергейм 10 из 10 сам, пиаришь сам и продаешь сам, да еще успешно, либо всю жизнь работаешь и мечтаешь в стол. А скорее всего только мечатешь и нихуя не делаешь всю жизнь, как и все.
>пятую яхту
Чего мелочишься?
Мог 5 круизных кораблей купить.
Со светом и звуком, между прочим!
Я думаю, что 25 долларов - это слишком много для китайской игрушки.
>25 долларов - это слишком много
Для жмотов есть бюджетная версия.
А на сэкономленное тянку купим!
Бюджетную... Но зато лёгкую!
Не тянку, а резиновый член с али.
Кстати, как покупать и не палиться?
Тут всё как с нашим любимым попенсурсом - если хочешь без вирусов и прочих проблем, то конпелируй всё сам себе из исходников. Жидкий силикон продаётся в обычных магазинах для рукоделия - никто не будет спрашивать, что ты там собираешься из него отливать. Главное покупать "platinum cured" силикон - он будет дороже, но безопаснее для здоровья при контакте с телом. Обычный член отлить просто - многие этим занимаются, на Reddit можешь посмотреть подробные инструкции мастеров членоделия, есть даже пошаговые туториалы на Youtube без цензуры.
Хочешь себе синий член в форме Godot, угадал?
А я бы себе лучше Годетту сделал...
> Главное покупать "platinum cured" силикон
Тут-то продавец и улыбнётся понимающе.
>Годот вообще может деньги принести?
Чел, глянь на результаты опросника по годоту, где разрабов спрашивали, какие игры они делают на годоте. Там абсолютное большинство "делают" 3д фпс шутеры. Да, на годоте. Можешь сам глянуть сколько успешных 3д шутеров было выпущено на этом игровом движке. Судя по всему доступные технологии привлекают всяких дегенератов, поэтому их столько и набежало. А те, кто зарабатывает деньги, в основном на юнити пилят 2д индюшатину, тут ты прав. Исключения конечно есть то тут, то там, вроде вон из успешных у детей на годоте это webfishing или как-то так.
Никакого противоречия. 3д шутеры делают сейчас, значит сделают их позже. 3д шутер делать дольше чем 2д игру. 4-ка не так давно стала популярной.
>большинство "делают" 3д фпс шутеры
Кто тебе это сказал? Ты опрос смотрел?
>сколько успешных 3д шутеров было выпущено
Опрос был о "текущих проектах" (current projects).
Во-первых, коммерческих отчиталось всего 499.
Большинство ещё делает или делало мелкоигры.
Во-вторых, жанры-лидеры в опросе были:
- платформеры (platformer): 3293
- РПГ (roleplaying game): 3217
- пазлы (puzzle): 2499
- рогулайты (rogulite): 2492
- стратегии (strategy): 2287
Шутеры только на 6-й позиции: 2202.
Но под "шутерами" скрываются также 2D проекты.
В-третьих, большинство делают 2D и не трогают 3D.
Почему же "first-person"/"third-person" в топе жанров? Основная причина в том, что это вовсе НЕ жанры, а определённый вид (view) 2D/3D игр любого жанра. Независимо от жанра 3D игра должна иметь камеру, которая может быть только двух типов: FPV/TPV. Становится очевидным, что большинство, кто как-то взаимодействует с 3D, поставил галочку на FPV/TPV. Относительно редко эти термины используются в 2D, поскольку почти всё 2D = TPV, но бывают и 2D FPV.
Ещё раз: "first person (view)" - "вид от первого (лица)".
Не путать с "first person shooter" - "стрелялка с FPV".
P.S. Опрос как всегда плохо составили, на мой взгляд. Особенно обосрались с выбором "жанров" в списке... Например, где там модный "open world survival craft"? "Survival" зачем-то смешали с "battle royale" (wtf?). Вот категории "sports/simulation" и "tycoon/management" - интересно, в какую из них засунуть "colony simulator"? Стратегии немного не про то ведь. А "farm simulator"? Бредовая подборка противоречащих жанров. Ещё и засунули зачем-то FPV с TPV, когда многие 3D игры поддерживают несколько видов камеры сразу. И 2D, конечно же, в большинстве случаев относят к TPV (исключением можно сделать 2D FPV квесты).
Кто-нибудь тут разбирается в левелдизайне?
Всё понимаю, всё умею... на базовом уровне... Но вот фантазии совсем не хватает ни на что. Как я вообще должен придумывать что-то... эдакое? Везде пишут базовые вещи типа "поставить вышку чтобы игрок заинтересовался", "делать линии, ведущие к цели", "комбинировать передний и задний план" и т.п. Но непонятно, как вообще дойти до чего-то из ничего.
Вот я умею CSG ноды лепить друг на друга. И делал множество пробных "уровней" для своих простых прототипов... Но дальше условных кубов моя мысль отказывается двигаться. Типа, накидал кубы, и что? Конкретной цели у меня нет, сюжета не будет. Мне хотелось просто что-то интересное сделать. Но что? Непонятно, как левелдизайнеры это решают.
Какие-то идеи у меня были, но все они какие-то уж слишком пресные, банальные. Пробовал нейронки - текстовые, графические - они тоже что-то банальное генерируют. Игры чужие смотрел - всё одно и то же. Непонятно... Просто случайный мусор лепить? Но неинтересно же, когда всё налеплено абы как.
А без левелдизана игры не получится.
>Но непонятно, как вообще дойти до чего-то из ничего
Есть каналы разбирающие уровни, найди канал левел дизайнера и попробуй посмотреть. Например левелдизайнер из ремеди https://youtube.com/@kirbuyanin
Есть тематический тред >>561988 (OP)
Ребят, пилю игру на годоте, первый мой проект, эрпэгэ-рогалик. Прошу рейтануть визуальный стиль, в целом игра так и будет выглядеть. Медленно, но верно двигаюсь к концу разработки, многое уже реализовано, скоро буду к звукам приступать.
>доступные технологии привлекают всяких дегенератов
Да. Умный способен на чём угодно сделать игру, пока дегенераты выясняют, чей движок лучше.
Видел тебя в субшоте. Молодец. Красиво выходит.
Освещение встроенными нодами сделал ведь? Попробуй добавить normal map спрайтам камней:
https://docs.godotengine.org/en/stable/tutorials/2d/2d_lights_and_shadows.html#normal-and-specular-maps
Должно получиться интереснее, особенно пол.
Спасибо. Неделю или больше убил на создание освещения, пытался сделать по красоте, чтобы объекты отражали тень, колонны там, сущности всякие. Но столкнулся с тем что физически невозможно сделать так чтобы факел размещённый на стене, мог освещать стену, которая точно также и является окклюдером теней (стены всегда были в тени), и также не смог или не до конца понял как сделать правильный окклюдер анимированным спрайтам, чтобы он учитывал изменение спрайта. По итогу неделю натурально ебался, а по итогу нихуя не вышло, и пришлось делать просто много Light2D с разными текстурами света) Увы, не осилил.
В будущем, когда вся игра будет готова полностью, попробую ещё раз переработать свет полностью, чтобы добавить и тени и прочую муйню, но пока есть вещи поважнее :)
..а ещё что такое "субшот"? Имеешь ввиду скрины в одном из предыдущих тредов? Ибо больше я никуда скрины не публиковал :)
Это как в дизайне персонажей, влияет насмотренность. Чем больше вникаешь в чужой удачный левелдизайн, тем лучше получается свой. У меня игра с упором на левелдизайн, и если в начале я тоже лепил кубы, то теперь прям доволен, вертикальность, разнообразие, крутые формы, ух бля. Тем временем мой каталог с рефами, куда я складываю скрины чужих игр с хорошим дизайном, распух до 2гб. Это моя сокровищница нахуй, а я дракон, собираю все больше и больше.
Норм. В целом выглядит как любой другой пиксельный эрпогэ рогалик. Визуально ничем не выделяется ни в плохую сторону, ни в хорошую.
>что такое "субшот"?
>>1018879 (OP)
Все темное, что происходит вряд ли будет понятно. При этом есть свет с градиентом который выбивается из пиксельного стиля.
Пролистал весь тред, не нашёл свои скрины (и слава богу, уже охуел с того что кто-то мои скрины куда-то заливает)
Видимо чел ошибся.
Значит с уникальностью проблемы. Попробуй чтоль шейдер какой сверху накинуть странный. Узнаваемость важна. Если твоя игра выглядит как 50 других игр того же жанра, то, ну, сам понимаешь.
>Ибо больше я никуда скрины не публиковал
>>1031732
>кто-то мои скрины куда-то заливает
Даже на Reddit не заливаешь? Я просто точно помню, как видел какие-то посты с рогаликом, который выглядел почти точь-в-точь как твой скриншот... Особенно GUI очень похож был. Автор поста вроде бы спрашивал, мол, "нормальный GUI для рогалика или нет", или что-то в этом роде. Я ещё много постов с разными играми тогда открыл... но сейчас тот пост найти не могу.
>>1031696
>невозможно сделать так чтобы факел размещённый на стене, мог освещать стену, которая точно также и является окклюдером теней (стены всегда были в тени)
Я покопался в 2D нодах, и там можно назначить битовые маски источникам света, теням и спрайтам. Если разместить два источника света - на стене и ниже стены - и настроить слои свету, теням и освещаемым спрайтам (нужно всего 2 слоя), тогда можно добиться эффекта "факел виден на освещённой стене, но эта стена отбрасывает тень на пол позади неё". Единственная проблема, которую я так и не смог решить - получается 2 отдельных тени "от пола" (перекрывающая только пол) и "от потолка" (перекрывающая стены). Выглядит нереалистично.
В общем, мне кажется, добиться на 100% реалистичных 3D теней можно только в 3D или какой-то особенной магией шейдеров (там какой-то рейкастинг добавили недавно). У тебя стены на самом деле плоские квадраты, а ты хочешь тени, которые огибают стены, как будто это 3D параллелепипеды, если я правильно понял...
В крайнем случае можно сделать оверлей (через SubViewport), на котором рендерятся 3D тени вокруг 3D параллелепипедов - которые на экране не отображаются. Но с этим подходом возникнуть проблема сортировки по Y, мне кажется. Особенно если источники света будут передвигаться... Да и с таким подходом будет проще сразу всё в 3D сделать, с пиксельными текстурами и 2D персонажами, лол.
Но normal map и specular map в 2D можно использовать вообще без "теней", потому что они работают только на "источниках света". Нужно только выставить значение "height" отличное от нуля (источнику света). Попробовать сгенерировать карту нормалей для нарисованных вручную спрайтов/тайлов можно здесь, должно работать с любым рисунком:
https://cpetry.github.io/NormalMap-Online/
Ну, просто предлагаю вариант, смотри сам, нужно тебе это или нет. Но современные "пиксельные" игры часто используют этот трюк, как мне кажется. Делает картинку живее...
Я тебе больше скажу - видел точь в точь такое же уже опубликованным в стиме, пока в распродажах копался.
Если не сложно, я был бы признателен если бы ты нашёл похожие скрины на Reddit, ибо да, я не публиковал туда ничего.
Насчёт нормал-мапов - я думал об этом, это и реализовать будет не так сложно (до пиксель арта я как раз 3д графикой и текстурированием занимался, понимаю че там к чему) но я хочу сделать прям максимально доступную игру в плане производительности. Если когда нибудь найду способ, было бы круто портировать на какое нибудь древнее говно, типа геймбоя мб или ps1 (вся графика уже нарисована не только в 640х360 но и в 320х180), поэтому пока таких примочек не планирую точно.
Да и похуй на самом то деле, главное что я сам для себя знаю что нигде ничего не спиздил, а что там у кого похоже - хуй с ним. Сейчас каждая вторая игра использует интерфейсы с простыми полупрозрачными панельками без какого либо визуального стиля в принципе. А у меня хотя бы так :)
Вряд ли смогу найти теперь...
>прям максимально доступную игру в плане производительности
Делаешь игру на Godot 3.6? У Godot 4.x требования выше, а Godot 4.5 x64 отказывается от старых и бюджетных процессоров без поддержки SSE4.1/SSE4.2. Но вообще, даже с Godot 3.6 минимальные требования у Godot, ИМХО, выше, чем, скажем, у SDL2 (достаточно для 2D пошагового рогалика). Посмотри исходники Shattered Pixel Dungeon - он, вроде, хорошо оптимизирован для рогалика с графикой под мобилки.
>портировать на какое нибудь древнее говно, типа геймбоя
Есть какие-то инструменты для этого, но наверняка придётся переделать игру на них.
>поэтому пока таких примочек не планирую точно
Старые игры часто "отупляли" при создании портов на очень ограниченное железо. Многие порты на Game Boy были только отдалённо похожими на оригинал с "большой" приставки. Типа оригинальная игра весит ~700 Mb, а "порт" лишь ~2 Mb... Не вижу проблемы сделать навороченную версию на ПК и потом сделать "мини"-версию для древней приставки.
>Все темное, что происходит вряд ли будет понятно.
Наоборот, слишком светло для данжа и слабый контраст.
Пятно света вокруг героя наверняка перемещается за ним.
>свет с градиентом который выбивается из пиксельного стиля
А это уже давно норма для современных "пиксельных" игр...
SDL2 софтверный, если туда добавлять свет, тени, нормали, то не факт что это все будет уже шустро. А шейдеры туда добавлять замучаешься. Насчет SDL3 не знаю, но там скорее всего тоже не все просто.
Я использую godot 4.3, только потому что мне порекомендовали именно его в начале разработки :) Я знаю про пиксель-данжн, он вроде на джаве написан и/или сделан. Очевидно что там лучше с оптимизацией вообще всё, в отличии от проекта созданного на каком либо движке. Но в любом случае, пока что так. Потом, когда будет больше скилла, можно и переносить на другие движки/платформы, а пока что меня и так устраивает всё.
На скриншоте неработающая хрень я тупой.
Короче пока решил хуй забить на вывот дня недели в сам экспорт годота.
Просто сделал, что в зависимости от дня (1, 2, 3) высчитывается день недели который нужно написать.
>и слава богу, уже охуел с того что кто-то мои скрины куда-то заливает
свин гд начинал с этого свою карьеру в 2016, воровал скрины для своего паблика вконтакте
> Йопта помогите.
>>1031784
Как-то так, но это не точно.
>SDL2 софтверный, если туда добавлять свет, тени
Простейший свет тайловой 2D игре можно сделать растягиванием чёрно-белой текстуры очень низкого разрешения, на которой 1 пиксель == 1 тайл, белый - освещённый, чёрный - неосвещённый. Если текстура растягивается с линейным фильтром, получается интересная и дешёвая имитация мягких теней.
Сложнее сделать алгоритм распространения света. Теоретически подходит клеточный автомат, но нужно учитывать источники света за пределами экрана...
>>1031778
>godot 4.3
До сих пор до 4.4 не обновился? Там много всякой оптимизации подвезли. Как правило, переход на следующую минорную версию (x.Y.z) должен быть безболезненным, но лучше сделать бэкап проекта.
>Потом, когда будет больше скилла, можно и переносить на другие движки/платформы, а пока что меня и так устраивает всё.
Согласен. Я как-то пытался свой движок написать, но ниасилил, перешёл на Godot с мыслью "сейчас игру проработаю, а потом переделаю на свой велосипед". В результате я так и остался тут... Godot комфортнее.
Можно использовать enum как на скриншоте. В GDScript enum работает как Dictionary:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#enums
>>1031802
Так делать не стоит, у Godot встроенная система локализации:
https://docs.godotengine.org/en/stable/tutorials/i18n/internationalizing_games.html
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/importing_translations.html
Использование enum очень хорошо сочетается с локализацией.
Не хочу использовать внутреннюю систему локализации годота, хочу жрать говно самостоятельно.
Нууу... ты так пишешь как будто надо читать документацию и делать игры. Но мы не хотим делать игры, мы хотим делать себе проблемы и потом героически их решать.
проверка
самое сложное как не странно это самое неочевидное.
баланс, и генерация. в случае с балансом можно просто через тысячи тестов ещё как то что-то сделать удобоваримое, а вот генерацию пилить это пиздец. я потратил на генерацию предметов, объектов, врагов, генерацию характеристик для этого всегда, а самое главное на генерацию уровней - больше половины времени что я в целом игрой занимаюсь. а я к слову, только спрайты и графику рисовал около трёх месяцев :)
короче для новичка вообще не то, вот прям совсем. меня выручило то что я рисовать умею и музыку писать, и плюс имею по 14-16 часов свободного времени в день на обучение и работу, сложно только с кодом, но убедил себя тем что в голове могу сам "логически накодить" что там и как должно быть, в плане идей то есть проблем не было.
но конечно взялся бы я условно за какой-нибудь простенький часовой хоррор, или новеллку - уже бы сделал скорее всего.
я в блендере около 4-х лет работал, и хорошо запомнил правило что даже на минорные версии нельзя обновляться в рамках одного проекта. каждый проект на своей версии типа. а иначе полный ад и израиль, заебёшься всё выправлять, и не факт что потом переход на предыдущую версию поможет.
изначально я вообще хотел на 3.х.х версии делать, но чёт мне сказали там хуйня и вообще говно, но гайдов на неё конечно поболее будет.
Если и перекачусь, то только после релиза основной игры (может демки) когда надо будет новый контент добавлять.
Дополню, что с enum можно как с числом обращаться.
>>1031841 >>1031842
Опять несмешные шутки пошли...
Godot: Уроки Обречённых
Godot не Blender, все основные "поломки" были между 3.5 и 4.0, да и то исправить было несложно. Разработчики пишут в документации гайд по миграции на новую версию:
https://docs.godotengine.org/en/stable/tutorials/migrating/index.html
При переходе с 4.3 на 4.4 большинство проблем у пользователей C# из-за API.
Папку проекта (где лежит файл "project.godot") можно считать почти полностью независимой, поэтому если сделать копию ("Project" -> "Project — копия" на Windows), и открыть копию в новой версии редактора (можно просто перетащить "project.godot" из папки-копии на Godot.exe), то старая версия никак не изменится. В менеджере проектов вроде есть кнопка копирования, но лично я просто папки в Проводнике копирую, лол.
И если проект большой и серьёзный, то лучше Git научиться пользоваться...
>>1031852
>потратил на генерацию
Удавалось поиграть в игру на ранних стадиях? Подвох процедурной генерации в том, что обычно она не создаёт интересный геймплей сама по себе... Поэтому её стоит делать в последнюю очередь, когда всё уже более-менее работает без неё. Генерация должна расширять контент в ширину, тогда как игровые механики задают глубину геймплея.
>короче для новичка вообще не то, вот прям совсем
Просто нужно начинать со статичной версии (пара подготовленных карт, пара врагов, пара оружий, пара зелий и т.д.), тогда и новичок справится. А генерацию добавлять постепенно, по мере необходимости (захотелось варианты врагов - сделал генератор врагов и продолжаешь играть; захотелось новых карт - нарезаешь существующие карты и делаешь генератор из уже имеющихся кусочков).
>простенький часовой хоррор, или новеллку
Зато с рогаликом ты многому научился, а чему бы ты научился с новелкой?
>Godot: Уроки Обречённых
>look inside
>Horus x SharOn - Поезда (Lyric video AI)
Ты там опять напился на выходных?
Зачем им второй и третий символ, если они одинаковые? Могли бы оптимизироваться и просто первый писать.
А слово "day" (день) в английских днях недели тебя никогда не смущало?
https://en.wiktionary.org/wiki/Monday
>From Middle English Monday, Monenday, from Old English mōnandæġ (“day of the moon”), from Proto-West Germanic *mānini dag, a calque (interpretātiō germānica) of Latin diēs Lūnae, equivalent to Moon + day.
https://en.wiktionary.org/wiki/%E6%9C%88%E6%9B%9C%E6%97%A5
>Compound of 月曜 (getsuyō, “moon”, in reference also to the day for that celestial body, as originally imported from Chinese astrology in the Heian period) + 日 (hi, “day”).
>The compound form suffixed with 日 (hi, “day”) appears in common use from the Meiji period with the promulgation of the Gregorian calendar. See also:
https://en.wikipedia.org/wiki/Names_of_the_days_of_the_week#East_Asian_tradition
Короче, это просто слова такие. 月 - буквально "Луна", 日 - "Солнце". Мы же ведь не сокращаем "понедельник" до "пн" в разговорной речи? Хотя могли бы: "увидимся в пн".
У нас *недельник не фигурирует в каждом дне. Ты же не говоришь пятнидельник, средельник, поэтому у нас уже нечего оптимизировать. А у них - есть.
Всего 3 нажатия кнопок. Куда оптимальнее?
Лучше свою игру оптимизируй давай.
Из-за таких как ты у нас потом ААА индустрия считает 30 фпс силки смуз. А своя игра у меня уже оптимизирована. В голове.
>Опять несмешные шутки пошли...
По-моему пиздец как смешно: додик делает пикрилейтед, потом просит помощи в треде, а потом два анона одновременно высмеивают эту ситуацию с велосипедом.
индигеймдев стабильно может приносить бабки только если ты делаешь фури-яой визуальную новеллу на патреоне
все остальные успешные инди разрабы кто не делал фури прон - ошибка выжившего которых можно по пальцам пересчитать
Я в соцсетях подписан на пару хуесосов, которые до релиза, даже до демо, умудрились собрать пару тыщ баксов. И нет, это не известные геймдевы, у которых в бекграунде имеются успешные проекты. Это ноунеймы с 2 играми на итче - их опыт как разработчиков хуй да нихуя.
- Чтобы продолжить работу, мне нужно оплатить мои BILLS, накидайте 600 баксов, а в следующем месяце еще 600.
- Открываю продажу ингейм портретов своим бэкерам, 1 портрет 150 баксов.
- Мой ноут ЗДОХ, накидайте 1к на новый, а то никакой игры.
При том что это не фури-яой. У одного лоуполи TPS, у второго пиксельный однобитный сблев. Я хз как это работает. Чисто за счет маркетинга и раскрутки соцсетей?
>патреоне
Кофи так-то меньший процент берет.
Во внешнем мире, не в снг? Если да, то почти везде культура оплачивать даже пердеж в подушку с детства прививается, не всегда успешно, особенно если денег нет, но все же там больше людей для которых норма "о, мне нравится что делает этот мужик, подпишусь ему на сотыгу баксов, чтобы потреблять его контент, он ведь так старается" вместо нашего родного "этот пидор потребляет мое время своим сраным девлогом и нихуя не выпускает игру уже пару недель и не хочет бесплатно, еще на деньги жалуется айтишный буржуй, игры делать научился значит панует мразь, буду ссать на него и его игру пока этот гной не выйдет в окно вместе со своим высером". Ну и конечно в любой культуре создатели нсфв контента и шлюхи привилегированы, даже наши дрочеры им на постоянной основе заносят, а потом еще и с распространением бесплатно помогают.
Слышал что так могут отмывать деньги, типа за ворованые плейстейшоны нал, закидывать себе.
Для этого НФТ вроде используют. Но в данных случаях у них там публичные донаты/типсы с никами, и куча комментов в соцсетях. Слишком замороченно, а пара тыщ - суммы для запада такие себе.
>умудрились собрать пару тыщ баксов
Зато если они обосрутся и не сделают игру за несколько лет, или сделают, но не выполнят всех обещаний, или выполнят всё, но недостаточно круто по мнению донатеров - эти же донатеры их потом заканселят повсюду, задоксят, будут следить и смеяться над каждым их шагом, вызывать на них ментов/SWAT, доводить их друзей и родных до суицида, срать на коврик под дверью, слать пожелания смерти и конверты с самодельными бомбами, и прочие радости жизни. А потом будут публично радоваться, если добьются суицида своей жертвы - добились своего.
Не давайте никаких обещаний и не берите денег без крайней необходимости.
Все это можно делать абсолютно бесплатно, повод не нужен.
замем? что бы использовать какую-то LLM-ку, например copilot или локальный сетап на каком-нибудь continue.dev.
собственно, что интересно мне, так это опыт с разными моделями. как хорошо они работают с godot скриптом? в особенности модели для автокомплита, какой-нибудь qwen2.5 coder, с чатом - хуй с ним, могу и в браузер переключиться
> использовал ли анон вместо встроенного редактора кода - vscode?
Не использовал.
Я использую, без ллмки. С гопотой пизжу просто, когда надо, потому что нищук для агентов. Юзаю, потому что редактор кода в самом годоте заставляет мои старческие глаза болеть. Было бы два моника смог бы стерпеть наверно. Печалит, конечно, что вскодовский плагин на все 100500% функции родного редактора не поддерживает, но что есть достаточно для хуйла вроде меня.
Жаль, что в годот никогда не добавят официально, ведь порватки в геймдев-индустрии будут визжать будто резаные, а годот известен своим "friendly" подходом. Было бы просто охуенно иметь ИИ бота для спрайтов прямо в редакторе, и отдельного ИИ бота для работы с кодом - разработка пошла бы в разы быстрее.
И правильно сделают что не добавят. Это сторонние инструменты, которые подключаются аддонами-плагинами. Опенсорс это не "добавьте все что я пожелаю", а тот, кто добавляет, берет на себя ответственность заниматься поддержкой. А на поддержку на избавление от ии-галлюцинаций и проверку чистоты получившегося кода надо очень много свободного времени.
Додстер, галлюцинация и чистота кода зависит от самой модели ллм, а не от сайд-панели в интерфейсе годота, годоту вообще не нужно об этом думать. Модель должна свободно выбираться из списка доступных на вкус пользователя, а панель в гуе должна интегрироваться нативно, а не аддонами. Как это сделано в курсоре и виндсурфе, но не только с кодом, а и со спрайтами.
>Додстер
Со своим отчимом так разговаривай.
>галлюцинация и чистота
Дохуя от чего зависит, в частвности цифирок (температуры, пенальти за повторы и так далее) которые надо подбирать под каждую модель. И кроме того выбор самих доступных моделей. Значит это какой то менеджер аля ассет стор. И потом мейнтейнеру придется гарантировать доступность всего этого. И гигабайтные скачивания. Короче любому адеквату понятно что этой шизе не место в КОРЕ.
> а панель в гуе должна интегрироваться нативно, а не аддонами
Никто никому ничего не должен.
Годот и так является сценой на самом движке, поэтому у аддонов нет проблем игтегрировать свои панели, так делают все от редакторов террейна до всяких анимаций до цепочек диалогов/квестов.
Единственное что надо сделать в коре - это улучшить поддержку языкового сервера для автодополнений.
>советовать нейросети для спрайтов
Кринж. Не пиши мне больше.
> Хотя могли бы: "увидимся в пн".
В понедельнике ещё есть буква Д. Поэтому можно говорить "Увидимся в пнд".
>Делайте игры
Моя реакция:
>заставляет мои старческие глаза болеть
Что тебя не устраивает в редакторе Godot?
1. Шрифт можно заменить на любой ttf файл.
2. Размер текста и отступов можно настроить.
3. Настраиваемое субпиксельное сглаживание.
4. Цвет фона и подсветка синтаксиса меняется.
5. Редактор кода можно открыть на весь экран.
6. Редактор кода отделяется в отдельное окно.
>>1032302
>vscode
Попробовал, но мне совсем не понравилось.
>>1032314
>в годот никогда не добавят официально
Официально они даже terrain не добавят никогда.
Ищи плагины - весь редактор гибко настраивается.
>иметь ИИ бота для спрайтов прямо в редакторе
Встроенного 2D редактора картинок в Godot нет.
Без ручной доводки JPGи от GenAI малополезны.
>>1032328
>должна интегрироваться нативно, а не аддонами
Зачем? По скорости отличий всё равно не будет...
В крайнем случае можно сделать свою сборочку.
>>1032334
>мейнтейнеру придется гарантировать доступность
Зачем, лол? Это же просто инструмент, а не сервис.
Вот в Godot есть свои собственные шейдеры.
А есть сайт https://godotshaders.com/ от годотера.
Но в Godot нет и не будет качалки шейдеров оттуда.
Скажешь, Godot обязан доставлять тебе шейдеры?
Так же и с LLM. API дали (плагином), дальше - сами.
>5. Редактор кода можно открыть на весь экран.
>6. Редактор кода отделяется в отдельное окно.
Там есть дерево проекта, а не путающий сблев со скриптами Там можно держать множество открытых проектов разом (например серверный код для игры еще)? Вообще что-то полезное, кроме самого дефолтного редактора, в таком режиме есть? Ну и зачем альтабаться на недоделанную иде, если можно альтабаться на вскод?
>порватки в геймдев-индустрии будут визжать
Отставить панику, Godot открыт для всех:
http://godotengine.org/asset-library/asset?filter=Assistant
http://godotengine.org/asset-library/asset?filter=LLM
Дальше ищи сам. Видишь? Никого не банят.
Алсо, у GenAI очень простой HTTP API. Читай:
https://docs.godotengine.org/en/stable/classes/class_httprequest.html
И подключай свой любимый GenAI своими руками.
Можно очень легко:
- запрашивать и получать картинки в @tool-скрипте;
- запрашивать и получать продолжение текста LLM.
Т.е. даже никаких плагинов не нужно.
>Там есть дерево проекта
Проблемы "дерева проекта (скриптов)" в Godot:
1. В Godot основа всего - это Сцена. Ты открываешь несколько вкладок со сценами. Работаешь с нодами открытых сцен. Работаешь с полями нод, ресурсами. Скрипты вторичны и почти всегда зависят от сцен.
2. Многие скрипты не нужно сохранять отдельно от ассоциированной сцены: он хранится внутри tscn. Открывается такой скрипт только вместе со сценой.
3. Скрипты, хранящиеся отдельно от сцен, обычно расположены в папке с родительской сценой и не используются независимо от этой сцены, т.к. сцена сохраняет экспортированные настройки скрипта.
Т.е. "дерево проекта" в Godot - это файловый док с сохранёнными сценами, а не список твоих скриптов. Открывай сцены и ассоцированные с ними скрипты.
>держать множество открытых проектов разом
Да, можно открыть несколько редакторов Godot.
>например серверный код для игры еще
Godot позволяет хранить всё это в одном проекте и настраивать отдельные шаблоны экспорта - для игры обычный, для сервера headless. В шаблоне экспорта выбираются папки, которые нужно включить в .pck. Подобным образом избегается копирование файлов.
>Вообще что-то полезное, кроме самого редактора
Не зажрался ли ты часом? В Блокноте кодил хоть раз? Рекомендую иногда дауншифтить на Блокнот, чтобы тренироваться. Или вообще писать код на бумаге. Это отрезвляет и обнажает пробелы в твоих навыках. Я стремлюсь отключать лишние костыли в IDE, а то окончательно растеряю программерскую хватку...
>зачем альтабаться
Не нужно альт-табаться, редактор скриптов сам будет выходить на передний план при нажатии на ярлычок скрипта в твоей сцене или в файловом доке. Окно это необязательно раскрывать на весь экран, так что тебе остаётся кликнуть на заголовок основного окна, чтоб вернуться. Поэтому можно alt+tab вообще не трогать. Возможно, это работает и с внешними редакторами: в настройках Godot можно указать путь до редактора.
Ты высасываешь претензии из пальца, как будто ты компенсируешь какую-то свою проблему. Чем тебя расстраивает VSCode, что ты тут лаешь на Godot? Довольный пользователь не будет доказывать, что выбранный им продукт лучше всех альтернатив...
Ты просто не врубаешься в кейс или горишь за годот и все что не он для тебя говно. Тебе не нужно дерево? Окей, твое дело ебаться по своему, а мне нужно Дерево есть в годоте? Есть. Отдельно от скриптов, не будет видно при развертке редактора на весь экран. Если мне их не разворачивать, то окошко для меня крошечное и не удобное. Список скриптов слева в редакторе бесполезная для меня хрень по навигации.
>Да, можно открыть несколько редакторов Godot.
>Godot позволяет хранить всё это в одном проекте и настраивать отдельные шаблоны экспорта - для игры обычный, для сервера headless.
Не на годоте же, что я считал очевидным из сообщения. Пока что я не дошел до уровня, где мне надо несколько редакторов годота для одного проекта иметь.
Вообще вот тебе мой кейс - клиент на годоте, серверный код на го/питоне, вспомогательные скрипты на баше с питоном, интеграционки отдельным проектом, фронт на вью. Хочу и работаю над всем этим сразу в одном инстансе вскода, запрещаешь? уже вижу твой ответ
>Не нужно альт-табаться, редактор скриптов сам будет выходить на передний план при нажатии на ярлычок скрипта в твоей сцене или в файловом доке. Окно это необязательно раскрывать на весь экран, так что тебе остаётся кликнуть на заголовок основного окна, чтоб вернуться.
Очень просто и совсем не говно, да. Главное что сова на годот натянута, остальное не важно.
>Чем тебя расстраивает VSCode, что ты тут лаешь на Godot?
Ты понял что сказал? Отвечу отдельно на части, а то во всем предложении виднеется диагноз.
1. Не расстраивает и не радует, вынужденная необходимость именно им пользоваться сейчас, был бы другой редактор я бы и к нему годот прикрутил ради удобства.
2. Этот лай с тобой в одной комнате? Был вопрос юзает ли кто другие редакторы, я дал ответ, быстренько вспомнив пару важных мне причин. И даже меня бы они не ебали в другой ситуации. А вот чем тебя так задевает мой выбор, раз важно меня переубедить любой ценой?
>Ты высасываешь претензии из пальца
Прости, что обидел, ты прав, мои претензии не претензии.
>окошко для меня крошечное и не удобное
У тебя 4:3 экран что ли? Мне 16:10 на всё хватает.
>Дерево есть в годоте? Есть.
>Список скриптов слева в редакторе бесполезен
Можно тогда скрыть список скриптов в редакторе, перенести каталог файлов на левую часть экрана и растянуть окошко скриптов вправо, всё будет норм.
>код на го/питоне
Так бы сразу и говорил, что велосипедист. Как ты серверную версию Godot запускаешь, чтобы физику обрабатывать? Или у тебя там карточная игра?
Обсуждали, кто пишет в VSCode на GDScript вместо встроенного редактора. Никто не спрашивал про совершенно другие языки в других проектах. Если использовать только GDScript, редактор Godot будет очевидным выбором, не так ли? Ты ж не сказал, что используешь кучу других языков и фреймворков на совершенно не связанных с Godot проектах.
Нормально всё с сокетами в Godot 4. Сервер можно спокойно писать и на GDScript. Читай туториалы, в документации есть основы. Но если у тебя мало геймдев опыта, лучше сначала сделай синглплеер.
Blender выкатил свою официальную игру на Годоте.
Да, 3 нормально использовать, 4-ка нужна только если прям ААА графон на ПК 4080 хочешь.
Смотря какая игра. Если скажем шутер, то логичней и сервер делать на годоте (а ля квейк/каэсик), в режиме headless. Когда физика считается пульки летают, просто не рисуется графон. И потом рассылается клиентам.
А твой вариант хорош для каких то пошаговых игр, типа вести прогресс в аккаунте матч-3.
Тебе - уже не надо пересаживаться, просто подпрыгни на своем стуле.
если конечная цель захостить с возможностями:
- автопоиска соперника для игры
- создание акков
то онли годот подойдет получается?
не выйдет ли код сильно больше или медленнее если писать на гдскрипте вместо чего-нибудь там?
ну у меня графона много не будет. и физики тоже. по сути да - уровень три в ряд, тоже пошаг, только логикой посложнее. что значит хедлесс? типа на сервере только данные без рендера как я прогуглил щас, но разве так не вообще любой мультиплеер работает?
>>1032853
по-моему мимо
Не любой, игра может быть и peer to peer - когда клиенты просто между собой общаются.
Тут в чем может быть нюанс. Допустим ты сделаешь клиент на годоте а сервер на питоне. Ну во первых тебе игру почти два раза писать на разных, хоть и похожих языках. Во вторых нет гарантии что ты не напутаешь и похоже выглядящая конструкция будет вести себя по разной логике. Как банальный пример - округление какое нибудь. То есть делать сервер на годоте звучит более логично. Но его может быть сложнее захостить, потому что в вебе все таки все задочено под популярные языки, а тут надо что то вроде vps.
если ты про сами языки, то опыта в питоне у меня нормально. просто бекендом я не занимался никогда. почему игру почти два раза надо будет писать? логика - сервер, визуал - годо. попробую пока через питон.
> Но его может быть сложнее захостить, потому что в вебе все таки все задочено под популярные языки, а тут надо что то вроде vps.
Ну пчел, ну ты чего. Если ты делаешь что-то хоть сколько-нибудь уникальное-интересное-полезное, не важно в вебдеве или геймдеве, то тебе все равно свой впс нужен, с консолькой и всем-всем. А "заточки" это круды клепать и чужие докеры запускать. Тем более голый сервер зачастую обходится дешевле чем твои заточки.
Я пользуюсь разными бесплатными хостингами в которых есть консолька, но только под стек который есть, ну и в целом там сеть часто рассчитана на запрос-ответ, а не постоянную работу приложения.
> почему игру почти два раза надо будет писать?
Потому что в настоящих, качественных онлайн-играх игровые расчёты происходят на сервере и на клиентах независимо, но периодически синхронизируясь. Благодаря такой независимой работе становится возможно прогнозирование событий при низком пинге и точный учёт попаданий по хитбоксам. Ну и как вишенка на торте - надёжная защита от читеров.
>Ну и как вишенка на торте - надёжная защита от читеров.
Ага помню-помню, клиент симулирует потерю пакетов и летит по небу большими скачками. Защита / 10
На сервере не предусмотрели, что персонаж не может так летать. При потере пакетов он должен остановиться, потому что в пакетах от клиента прилетает инпут - нет пакетов = нет движения. А раз сервер допускает скачки на километр - это значит КГ/АМ.
И ещё это означает что сервер в синхронизации действует как вторичное звено, а должен быть первичным. Вся главная симуляция кинематики происходит на сервере, клиент делает свою симуляцию и сверяется с сервером, поправляя себя (а не сервер).
>Вся главная симуляция кинематики происходит на сервере
Ага, гуд лак.
Я вот щас не понял этого пассажа. Ты предполагаешь что игровые серверы онлайн-игр СЛАБЕЕ клиентов? Не, ну в таком случае конечно гудлак, просто я слышал ровно противоположное. Про серверные технологии.
Я не он, прост мимо проходил, но у меня большой опыт с серверами, больше чем в геймдеве. Серверное железо не магическое железо из будущего, оно просто заточено на параллельность вычислений. Кластеры из 100500 серверов в 100500 потоков. Если код, запущенный на серверах, не распараллелен нормально, то хуй там а не скорость. Поэтому в вебдеве принято городить кучу воркеров вместо одного процесса.
Дальше уже про геймдев и мои догадки. Долгое время я гонял в одну ммо-дрочильню, и она начинала жестко лагать, когда ~600 людей сбивались в кучу и агрессивно кастовали спеллы, эффекты которых высчитывались на серверах. Лагала в эти моменты она у всех, скиллы кастовались по 30 секунд вместо инстант каста, при этом пинг и фпс в норме, никакого раббербандинга, передвижение толпы персонажей работало ок, и было принято разбежаться по углам и дать серверу продохнуть пару минут. Полагаю у них задыхался нераспаралелленый числодробительный поток, обсчитывающий именно скиллы. Такшто как сделаешь так и будет.
> Серверное железо не магическое железо из будущего, оно просто мощнее твоей днищепекарни.
Пофиксил.
ты во многом супер прав друг.
насчёт первого тейка - да, я так и делал, основной тестовый уровень, и на нём все механики, предметы, эффекты, тестовые враги и так далее. генерация в последнюю очередь
насчёт того что многому с рогаликом научился? - да, бесспорно, душа поёт прямо насколько себя хорошо чувствую все эти недели и месяцы разработки потому что это мечта с пиздючества, когда в 11 лет пытался игры на ргм делать. а вот карман нихуя не поёт, могу делать по 12 часов день ТОЛЬКО потому что мне недавно только 20 стукнуло, и ещё полгодика гдет я могу себе позволить перебиваться случайными доходами, а потом когда придется сьезжать и платить за аренду и прочее, если к этому времени игра не начнет приносить хотя бы базовый доход - придется в долгий ящик забросить желание пилить игрульки.
Шутник, ты опять нашутил в тред не подумав? Анон правильно говорит: сервер == многопоточность и энергоэффективность, а ещё тонны RAM и PCI-E. Производительность одного ядра в 2 раза ниже, в противном случае датацентры просто сгорали бы. Информация свободно доступна онлайн - изучай.
>>1032966
В ММО обычно мир делится на локации, которые обрабатываются параллельно - на разных ядрах, процессорах, серверных нодах и т.д. Это даёт игре возможность содержать тысячи игроков в одном бесшовном мире. В одной локации игрокам обычно запрещают толпиться, но если разрешают, то игру, естественно, может начать трясти в этой локации. Остальные локации должны работать как обычно.
>>1032955
Во-первых, серверная симуляция физики сотни управляемых игроками персонажей почти не будет отличаться от симуляции 99 NPC и 1 игрока в чисто однопользовательской, полностью локальной игре. Единственное отличие в том, откуда приходит вся необходимая информация и куда идут результаты. Естественно, что в ММО игроки делятся на группы небольшого размера - симуляция идёт по локациям.
Во-вторых, симуляция на сервере часто значительно медленнее частоты кадров на клиенте: 15 Гц будет достаточно для условной ММОРПГ с автоматически наводящимися на цель навыками. По-моему, даже в соревновательных шутерах используют около 30 Гц. Симуляция на клиенте от 60 Гц и выше нужна ради плавности картинки без лишней интерполяции. Да и массово многопользовательские игры геймплейно оптимизируются: те же самонаводящиеся навыки значительно проще предсказать/интерполировать.
В-третьих, в синглплеере ПК нужно обработать массу информации, зависящей от результатов всего цикла физической симуляции: передвинуть модели, задать анимации, скрыть лишнее и показать нужное и т.д. В мультиплеере этим занимается в основном клиент, а передачу данных сервер может делать параллельно симуляции физики, т.е. нет искусственных задержек.
Короче, серверный CPU по ядру может быть слабее клиентского и при этом не сильно нагружен даже в массовом мультиплеере. Серверу нужны только многопоточность и широкий канал связи.
>>1032851
>конечная цель захостить с возможностями:
>- автопоиска соперника для игры
>- создание акков
>>1032858
>уровень три в ряд, тоже пошаг
Ты бы лучше больше подробностей рассказал.
Например, сколько игроков в матче? Будут ли у них рейтинги Elo? Соревнования? Таблицы рекордов? Специальный чат в глобальном/локальном лобби? Матчмейкинг выбирает кого угодно или оценивает удалённость клиентов друг от друга или их навыки? Создаётся ли игроками особый контент на сервере? Собираешься ли всерьёз монетизировать проект?
Возьмём самый примитивный вариант:
- никаких чатов, рейтингов и таблиц рекордов;
- матчмейкер соединяет первых попавшихся;
- в матче может быть всего лишь два игрока;
- туннелирование будет средствами Steam.
С такими вводными сервер пиши хоть на PHP.
Пример диалога с простейшим REST сервером:
>Клиент 1: Сервер, вот мой логин и пароль: ...
>Сервер: Всё верно, вот твой новый токен: ...
>(дальше клиент каждый раз прикрепляет токен)
>Клиент 1: Сервер, есть кто живой? (Мой токен: ...)
>Сервер: ≈20 матчей, 0 свободных игроков.
>(спустя 5 секунд)
>Клиент 2: Сервер, мой игрок потерялся...
>Сервер: Принято. Записал в свободных.
>(спустя 5 секунд)
>Клиент 1: Сервер, есть кто живой?
>Сервер: ≈19 матчей, свободный игрок: %2%.
>Клиент 1: Сервер, я смог с ним связаться.
>Сервер: Принято. Исключаю из свободных.
Дальше - общение клиентов через TCP или UDP:
>Клиент 1: Привет.
>Клиент 2: Привет. Начинаем?
>Клиент 1: Начинаем.
>Клиент 2: Жду твой ход.
>Клиент 1: Мой ход: [...]. Твой?
>Клиент 2: Мой ход: [...]. Твой?
>(сколько-то ходов спустя)
>Клиент 1: Мой ход: [...]. Победа.
>Клиент 2: Понял. Закрываю соединение.
В данном случае оба клиента - Godot-игры; сервером послужить может что угодно, на любом языке, и тебе наверняка хватит бесплатного хостинга, если там разрешается делать подобный сервис. Трафик тут минимальный и количество запросов маленькое относительно общения между самими клиентами.
В современном мире, конечно, потребуется туннель, наподобие хамачи, но можно не изобретать свой, а использовать готовое решение, например, у Steam:
https://partner.steamgames.com/doc/features/multiplayer/steamdatagramrelay
Но это если ты дойдёшь до публикации в Steam...
А если хочешь сделать рейтинги, таблицы со 100% честными рекордами, соревнования и так далее, то полагаться на описанное выше решение уже нельзя. Потребуется крутить на сервере все матчи по шагам, проверяя легитимность действий игроков и всё это записывая в БД в подробностях для статистики. Ну, разумеется, если хочешь надёжно-честную систему.
Вообще, для начала я бы посоветовал вообще без специального сервера обойтись. Реализуй сетевое взаимодействие игроков, знающих IP адрес друга. Разберёшься с TCP и/или UDP - это в любом случае пригодится; напишешь прототип своего геймплея...
А ещё лучше начинать не с TCP, а с вот этого:
https://docs.godotengine.org/en/stable/tutorials/networking/high_level_multiplayer.html
Чтобы не ломать голову пакетами и сокетами.
В статье пишут "TCP слишком медленный для игр": справедливо только для реалтайм игр на реакцию - пошаговым играм более чем достаточно TCP. Но использовать голый TCP тоже не так просто, как запрашивать веб-страничку через HTTP, например. Фактически нужно придумать свой "протокол", т.е. сообщения, их формат, содержимое и порядок.
Ну, а самое сложное в онлайн-играх - это игроки... Разработать простенький мультиплеер проще, чем заставить прохожих попробовать твою поделку. В особенности когда в поделку ещё никто не играет.
Мог в чём-то ошибиться - я только поверхностно разбираюсь в сети и мультиплеере, лично писал локальный TCP-чат только... Остальное знаю из множества каких-то статей про онлайн геймдев.
Интересно когда китайцы начнут делать рефаб материнки по EPYC и новые Xeon
Старые б/у EPYC уже можно купить, они были б охуенны как альтернатива сборкам на 12400-13400
Мимо любитель собирать бомж пк
Меню сверху > Scene > Export As... > glTF 2.0 Scene...
https://docs.godotengine.org/en/stable/tutorials/assets_pipeline/exporting_3d_scenes.html
Это очень полезно для прототипирования из CSG:
https://docs.godotengine.org/en/stable/tutorials/3d/csg_tools.html#exporting-as-gltf
Сделали это уже очень давно, вот новость:
https://godotengine.org/article/introducing-the-godot-gltf-2-0-scene-exporter/
>>1033449
Проблема в том, что новые серверные процессоры используют какие-то особенные сокеты, поэтому, я подозреваю, делать кастомные платы невыгодно. Выгоднее, наверное, продать сервер целиком.
В теории можно купить б/у "workstation", но там всё сомнительно устаревшее по сравнению с новыми геймерскими ПК, и придётся возиться с дровами.
>>1033447
Ты не понял. "Бесшовным" называют мир, в котором перемещение происходит без экрана "Loading...", но технически "швы" присутствуют в любом игровом пространстве достаточно большого размера.
В одиночной игре движок незаметно на фоне читает актуальные данные с диска по кусочкам (чанками), "выгружая" из памяти ставшие лишними кусочки. Телепортация через всю карту потребует "Loading...", поскольку движок не успевает прочитать данные.
В мультиплеере с огромным миром пользователей перебрасывает с одной серверной ноды на другую, распределяя нагрузку на сервер. Естественно, что потребуется хитрый алгоритм запуска и удаления параллельных локаций, чтоб всё было эффективно. Клиентская часть подгружает данные как в сингле.
Иногда можно заметить лёгкий "лаг" при быстром перемещении через невидимую границу, но с т.з. маркетинга мир по-прежнему "бесшовный" - нет прерывания геймплея загрузочным экраном.
Согласен про бесшовность, коме этого:
> Телепортация через всю карту потребует "Loading..."
В истинно бесшовной игре тебе покажут анимацию телепортации, и во время её будет идти подгрузка. Пример: Fallen Order и Survivor, где полёты на звездолёте это по сути та же телепортация, но ты бесшовно заходишь в кабину на одной планете, просишь пилота полететь, смотришь заставку с летящими звёздами из шиндовс 95 в иллюминаторах, и затем бесшовно выходишь на другой планете из корабля. Нам геймдевелоперам вполне очевидно что происходило под капотом, пока игрок всю эту синему созерцал. В 33 потока одна сцена выгружается, вторая загружается.
>Меню сверху > Scene > Export As... > glTF 2.0 Scene...
Спасибо.
Подвох в том, что ты
>заходишь в кабину
- это и есть "загрузочный экран", просто в 3D.
Есть разница между:
0. Есть старый ландшафт, он занимает память.
1. Загрузить интерьер корабля, не теряя ландшафт.
2. Закрыть окна корабля "летящими звёздами".
3. Выгрузить старый ландшафт, освободив память.
4. Загрузить новый ландшафт на место старого.
5. Показать новый ландшафт в окнах корабля.
И:
0. Есть старый ландшафт, он занимает память.
1. Загрузить новый ландшафт, не теряя старого.
2. Переместить игрока на новый ландшафт.
3. Выгрузить старый ландшафт.
Суть в том, что "корабль" легче "ландшафта".
А ещё, прерывает ли телепорт корабля геймплей?
Если геймплей - "бегать по ландшафту", то прерывает.
Поэтому телепорт на корабле ≈ загрузочный экран.
>вынужденная необходимость именно им пользоваться сейчас, был бы другой редактор
Почему так? Неужели программисты деградировали? Разрабатывают языки, но не могут простой редактор смастерить на своём "новом и быстром" языке, лол, полагаясь на выкидыши браузерного инцеста...
Дайте мне машину времени - удалю хромиум у гугла.
Лучше по сути всего один, остальное все однохуйственно. Но он платный.
>Лучше по сути всего один
>Но он платный.
Для соло индюков есть Delphi Community Edition.
Vs code сильно оптимизирован, я как то сравнивал с разными типа Geany который вообще на с++ - так нифига у них сравнимое потребление. Только у вскода плагинов в разы больше и делать их проще.
ну мне опять же не нужно прогнозирование никакое. у меня пошаг пошаговый.
>настоящих
не понял, ну как скажешь.
>>1033441
>сколько игроков в матче?
2.
>Будут ли у них рейтинги Elo? Соревнования? Таблицы рекордов?
было бы круто.
>Специальный чат в глобальном/локальном лобби?
нет.
>Матчмейкинг выбирает кого угодно или оценивает удалённость клиентов друг от друга или их навыки?
по скилу - было бы круто. по расстоянию - не знаю. можно ради опыта такое попробовать написать. по сути только матчмейкинг надо будет переписывать если что?
>Создаётся ли игроками особый контент на сервере?
не понял, ну вроде нет.
>Собираешься ли всерьёз монетизировать проект?
сложный вопрос. попробовать можно. но я понимаю что это уже вообще отдельный мир. бизнес короче.
>А если хочешь сделать рейтинги, таблицы со 100% честными рекордами, соревнования и так далее, то полагаться на описанное выше решение уже нельзя. Потребуется крутить на сервере все матчи по шагам, проверяя легитимность действий игроков и всё это записывая в БД в подробностях для статистики.
я так изначально это и представлял, потому что это более правильным кажется.
пока начал совсем с малого.
я попробовал сделать, но выглядит всё мудрёно, доступ к компонентам сущности выходит мега душный, по сути перебираются ноды в одной "папке" у "сущности", плюс в этой же "сущности" лежит прочая ерунда, которая нужна для функционирования игрового объекта, но пользоваться этим откровенно неудобно, постоянно приходится искать нужную ноду или перебирать "компоненты" в папке
Если тебе неудобно, то не делай. Поскольку такой подход не даст какого то большого ускорения (это не c++ ecs модуль например), то имеет смысл только если это как то упрощает разработку твоей игры. В моем жанре например проще использовать паттерны Action, Command, ecs-лайк я попробовал и отказался.
для навыков, чтобы они были разнообразные, я пока что не нашёл других вариантов, но я уже подумал, что для мобов и всего остального не использовать как вариант, ещё посмотрю твои паттерны, может подойдёт что-то, спасибо
Иногда компоненты это просто компоненты. Безо всяких ецс архитектур. Подумай над этим.
Делай просто через композицию/агрегацию ООП.
Пример, как сделать тулбар с выбором орудий:
>Player
>_ ToolBelt
>_ _ Shovel
Player + ToolBelt - это композиция (нельзя менять).
ToolBelt + Shovel - это агрегация (можно менять).
Player отвечает только за движение и ToolBelt.
ToolBelt отвечает за переключение орудий:
>class_name ToolBelt
>var current: TBTool # орудие в руках персонажа
>func _unhandled_input(event: InputEvent) -> void:
>_ for i in range(9): if _check_slot(i, event): break
>func _check_slot(id: int, e: InputEvent) -> bool:
>_ if e.is_action_pressed("tool_bar_%d" % [id + 1]):
>_ _ if get_child_count() > id: activate(id) # выбор
>_ _ return true # что-то нажали
>_ return false # ничего не нажали
>func activate(id: int) -> void:
>_ current.active = false # убираем в карман
>_ current = get_node(id) as TBTool
>_ current.active = true # достаём из кармана
Дальше орудие само делает всё, что ему нужно:
>class_name Shovel extends TBTool
>func _process(delta: float) -> void: ...
Обработчики _input, _process и т.д. отключаемы:
>class_name TBTool:
>var active: bool = false:
>_ set(v):
>_ _ active = v
>_ _ set_input(active)
>_ _ set_process(active)
И т.д. Это снизит нагрузку в рантайме.
Если нужны простые навыки как в TF2, Overwatch, Genshin Impact и т.п., тогда ToolBelt не нужен и ты можешь просто сделать всё через композицию. Конкретные клавиши навыков биндятся через инспектор, например, можно так:
>class_name Ability
>@export var ability_key: ShortCut
>func _unhandled_input(event: InputEvent) -> void:
>_ if not cooling_down and not disabled:
>_ _ if ability_key.matches_event(event): use()
>func use() -> void: # применяем способность...
Мне проще через код/json, хоть я и много лет сопротивлялся этому. Но игра сложнее среднего, поэтому мне нет смысла конфигурировать мобов через нодовый визуальный редактор.
Да, думаю первое как раз хорошо подходит по концепции, только toolbelt будет самим навыком, а его содержимое действиями, и последовательно их все выполнить, плюс можно динамически изменять их в процессе, наверно это наилучший способ, спасибо большое
>игра сложнее среднего
Покажи похожие игры из популярных.
>>1034166
>действиями, и последовательно их все выполнить
Что это за "навыки", которые состоят из действий, выполняющихся последовательно? Типа "запустить ракету/мячик/бумеранг, которая может выпустить зажигательный/замораживающий эффект, который действует по цели/по области/веером/дождём и уничтожается сразу/по таймеру/от сопротивления"?
Просто интересно. Обычно "навык" - одно действие.
_physics_process идет отдельно от фпс, как правило с фиксированным 60 тиков/сек, в настройках проекта это указывается. А если ты про дельту, то это другое, и так везде, просто где-то под капотом, где-то не.
Не привязан, но есть нюанс...
Если твоя игра лагает из-за графики (даже если вся нагрузка на видеокарту шейдерами) - физика тоже затормозит. Если лагает из-за физики (очень много ригидбоди сталкиваются друг с другом) - графика затормозит. Поэтому везде нужно учитывать delta.
Вроде бы пытаются полностью отвязать физику от графики многопоточностью, но она нестабильна...
>Если твоя игра лагает из-за графики (даже если вся нагрузка на видеокарту шейдерами) - физика тоже затормозит. Если лагает из-за физики (очень много ригидбоди сталкиваются друг с другом) - графика затормозит. Поэтому везде нужно учитывать delta.
А шо если резать резолюшн скейл, когда фпс начнет дропать ниже нужного значения? Правда не везде так легко получить отдельно цпу дельта и гпу дельта. Но если удается это сделать, то вот оно, стабильный геймплей со стабильным значением фпсов, даже если игра внезапно высралась огромным количеством дроуколлов.
А, и GDScript по умолчанию работает в один поток. А следовательно, код в _process и _physic_process будет происходить всегда последовательно и если одна из функций тормозит, другая будет запаздывать.
Работать с многопоточно сложно, особенно когда данные разбросаны и нужны в нескольких потоках.
Ещё и дерево сцены - это (пока что) один поток...
>резать резолюшн скейл
Видел такую фичу в каких-то играх на юнити. Как-то особенного ускорения не заметил. Уж лучше я буду страдать от 20 фпс, чем от пикселей на весь экран.
>геймплей со стабильным значением фпсов
Да, но тогда игра в самые напряжённые моменты (огромная толпа врагов окруживших игрока) будет внезапно либо "рассыпаться на пиксели", либо искажаться артефактами линейной интерполяции.
Видеокарты RTX 30/40/50 вроде позиционировали "ускоряющими рендер с помощью ИИ", и вот там рендеринг идёт в маленьком разрешении и потом растягивается с помощью какой-то нейронки, что заблюривает все мелкие детали в кинцо-мыльцо.
Возникает вопрос, нужны ли такие оптимизации?
А если нужны, не лучше ли урезать графику? Ну не используйте 4К текстуры, если у вас игра начинает тормозить и скукоживается до 360p с нейронкой...
>получить отдельно цпу дельта и гпу дельта
Посмотри класс Performance, там должно быть.
https://docs.godotengine.org/en/stable/classes/class_performance.html#enum-performance-monitor
Алсо, есть один нюанс:
>высралась огромным количеством дроуколлов
Draw call - это буквально вызов GPU API из CPU. Т.е. совершенно не важно количество пикселей, ведь замедление происходит из-за общения CPU с GPU.
Уменьшение разрешения экрана может помочь, если определённый шейдер загружает GPU на 100%. Т.е. уменьшая количество пикселей можно уменьшить количество вызовов этого шейдера на стороне GPU. Соответственно GPU станет доступна CPU раньше.
Но опять же, лучше упростить код шейдера или его полностью отключить, чем скукоживать картинку... Скукоженная картинка с любым шейдером плохая.
Сделай пиксельный рпг-рогалик в средневековом данжн сеттинге.
>пиксельный
Пиксели кто рисовать будет? Или тебе 8x8 тайлы?
>рпг-рогалик
Так РПГ (сюжет) или рогалик (дрочь механик)?
>в средневековом данжн сеттинге
У тебя такая свежая фантазия, очень удивил.
>>1034331
Делай то, что тебе самому нравится по жизни.
Иначе просто выгоришь и забросишь. Снова...
У меня фантазии нет самому что-то придумывать.
>Так РПГ (сюжет) или рогалик (дрочь механик)?
Можешь глянуть всякие children of morta, moonlighter, да и их дохуя подобных, айзека и то можно за яйца притянуть, сюжет то есть. Типа сюжет и развитие персов какое-то между посещениям рогаликовских данжей.
Это может называться rogue-lite.
Формально, "рогалик" (rogue-like) - это только те игры, которые соответствуют строгому определению... Но ньюфаги его запачкали, тыкая в каждую игру. Прост истинных рогаликов (которые ASCII) зумеры боятся.
Rogue-lite - это игры с элементами рогалика, но как минимум по одному параметру не соответствуют определению рогалика. Чаще всего там отсутствует пермасмерть и присутствует 2D/3D графика, и ещё последнее время стало популярным делать игру в реальном времени вместо пошаговости... Короче, от рогаликов в рогулайтах почти ничего не осталось.
Есть ещё понятие "dungeon crawler" - это вид РПГ, где необходимо исследовать подземелья с монстрами. Рогалики и некоторые рогулайты эти подземелья процедурно генерируют, так что они являются РПГ разновидности "dungeon crawler", но с жёсткими (у рогулайтов - не очень) жанровыми рамками.
Но в то же время к "РПГ" чаще относят игры с более определённым линейным сюжетом, особенно jRPG.
Короч, "РПГ-рогалик в сеттинге данжа" - это фраза из разряда "масляное масло с наполнителем из масла".
Этот шарит. Налил бы тебе масла в твою масленку, если понимаешь о чем я.
Ну, я понимаю рогалик как роглайт тогда. Хоть мне и 34 я соглашусь с зумерами, православных аски рогаликов не видел и чето не хочется после твоего описания, собственно даже любителем роглайтов не являюсь. В общем будет средневековый не рогалик, а чето типа мунлайтера.
> Что это за "навыки", которые состоят из действий, выполняющихся последовательно? Типа "запустить ракету/мячик/бумеранг, которая может выпустить зажигательный/замораживающий эффект, который действует по цели/по области/веером/дождём и уничтожается сразу/по таймеру/от сопротивления"?
Ну вроде того, да, или даже я больше ориентировался на систему карт в slay the spire, или всяких доталайк вроде пикрил
То есть, допустим, навык должен наносить урон, отравлять врага и менять активного персонажа, или вешать дебафф и на врагов, и на союзников, или что угодно, в общем, надо систему, предоставляющую большую возможность комбинирования
Как пример навыка, будут примерно такие действия внутри я думаю:
- кликабельный на врага (открывает возможность нажать на врага, добавляет в массив "получателей" нажатого врага)
- уменьшить очки действия игрока (допустим у каждого навыка есть значение стоимости)
- нанести урон (применяется к каждому получателю в массиве)
- повесить дебафф (применяется к каждому получателю в массиве)
Или допустим массовый навык:
- уменьшить очки действия игрока
- выбрать всех врагов(добавляет всех врагов в массив "получателей")
- нанести урон случайному получателю в массиве 1 раз X3 раза
- повесить дебафф с длительностью, пропорциональной размеру массива "получателей"
- нанести урон игроку
И навык при использовании должен запустить цепочку компонентов по очереди
Возможно, есть что-то более простое для таких штук, я пока что не придумал/не продумал
>Нахуя нужен Godot, если есть анрил или юнити ? Какие преимущества я получу ?
Отсутствие анального зонда от корпов
Если корпы захотят задним числом изменить лицению, то на юнити и уе тебе пизда
На годоте такое невозможно
Моя причина - для одинокого анскильного хрыча лучше подходит. Юнька и уе либо для молодых и шутливых, либо для команд, которые нацелены из этих монстров все до последней капли выжимать и драться на мечах за правильность. А я тем времени на годоте клиент для чатагпт вон сделал и почти не стыжусь этого.
>Какие преимущества
По сравнению с несвободными условно-бесплатными и платными движками (Unity, UE и т.д.):
1. Движок на 100% бесплатен, никаких "условий мелким шрифтом", даже если ты станешь долларовым миллиардером с его помощью - ты никому никогда ничего не будешь обязан. Это условие точно никак не изменится в будущем благодаря следующему пункту.
2. Движок на 100% состоит из свободных исходников, т.е. любой может скачать бесплатно и без регистрации исходники движка с GitHub и делать с ними что угодно - хоть продавать в ларьке на дисках, хоть использовать для нового движка - никаких ограничений нет.
3. Следовательно, ты можешь бесплатно и без проблем изменить нужные места в исходниках движка и сделать свою сборку, подходящую конкретно под твою игру, ни с кем об этом не договариваясь, никому об этом не сообщая и так далее - лицензия позволяет.
4. В связи со всем этим в сообществе движка собралось много идейных людей, готовых за идею выкладывать свои наработки совершенно бесплатно и под свободной лицензией, часто совпадающей с лицензией движка. Качество не идеально, но количество растёт.
5. Эти же люди готовы бесплатно помогать другим разработчикам игр на форумах, в чатах и т.д. Сообщество практически не имеет токсичных и алчных людей, озабоченных только прибылью - большинство пришли к этому движку ради игры мечты, а не очередного ассетфлипа.
6. Развитие движка идёт не в интересах прибыли компании-владельца движка, а в интересах его сообщества, потому что другого смысла в существовании движка кроме как удовлетворении интересов его сообщества не существует (с пожертвований не разбогатеешь).
7. С движком не идёт никаких лишних недоделанных инструментов, что добавляются в условно-бесплатные движки по запросу маркетингового отдела лишь ради привлечения внимания; в приоритете всегда багфиксы, оптимизация и поддержка (по возможности, конечно).
8. Благодаря свободности исходников и идейности последователей, надёжная поддержка Linux и связанных с ним платформ, тогда как у условно-бесплатных в приоритете только Windows. Есть даже сборки редактора на Android с ARM процессором и для запуска в браузере.
По сравнению с другими бесплатными свободными движками:
1. Условия лицензии движка позволяют делать на нём игры с несвободным исходным кодом, не требуют распространять исходники движка, не накладывают ограничений на лицензирование, перепродажу и т.д. Единственное условие - добавить где-нибудь "сделано на Godot".
2. Имеет долгую историю (с начала 00-х) и опытных разработчиков, которые делали свои игры. Поэтому к нему есть полноценные туториалы, демки и очень хорошая документация, большую часть которой встроили прямо в редактор сцен и скриптов, что очень удобно.
3. У движка больше всего разработчиков и пользователей среди всех открытых движков того же уровня, поэтому он развивается быстрее остальных, держится за актуальные технологии и платформы, имеет большое количество обучающих материалов, достаточный бюджет.
4. Имеет встроенную в редактор онлайн-библиотеку бесплатных дополнений, а также вскоре будет поддерживать продажу и покупку платных дополнений, но ни к чему не обязывает.
5. Крайне компактный редактор, без лишних гигабайт непонятных файлов на диске.
По сравнению с фреймворками, сборками из библиотек и т.д.:
1. Полноценный "что видишь, то и получишь" редактор сцен с приятным GUI.
2. Удобный язык скриптов, достаточно быстрый и компактный для своих задач.
3. Всё уже собрано, достаточно скачать один маленький EXE и делать свою игру.
4. Экспорт игры на основные платформы без компиляции - быстрый и надёжный.
По сравнению с конструкторами игр и специализированными движками:
1. Не накладывает серьёзных ограничений на жанр игры (типа "только RPG"/"только VN").
2. Легко найти демки, шаблоны и плагины на любой жанр игры без возни с костылями.
3. Потенциал развития в коммерческом плане (использовался даже в автомобилях).
Недостатки - как у любого бесплатного свободного программного обеспечения...
>надо систему, предоставляющую большую возможность комбинирования
Может ли игрок сам (через GUI) составлять комбинации из этих действий?
Если игрок не может ничего изменить, т.е. это не песочница "сделай сам", тогда тебе нужен будет баланс в игре. А баланс строится вокруг какой-то структуры... Даже если ты можешь технически соединить любые действия в любом порядке, странные комбинации могут сильно нарушать баланс и дезориентировать игрока. Например, очки действий должны учитываться в какой-то фиксированный момент, скажем, сразу после использования навыка; клик на врага или товарища должен всегда приводить к урону/лечению/баффу/дебаффу, а не к чему-то неожиданному; урон игроку должен приходить в одно и то же время у всех навыков и т.д.
С точки зрения балансирования игры проще предсказывать исход боя, когда все навыки следуют какой-то заранее известной формуле урона, а у всех персонажей одна заранее известная формула защиты. Так проще построить графики и вести расчёты в табличках.
С точки зрения геймплея игроку проще понять, что делает только что открытый им навык, проще встроить его в свой стиль игры, проще запомнить и использовать комбинации. Не нужно запоминать "исключения", сформированные против общей структуры навыков.
Абсолютная свобода может быть нужна только если игра позволяет игроку делать любые, даже бессмысленные комбинации, в каком-нибудь симуляторе боя, где герои сами все эти способности используют и этим доставляют удовольствие (игра без игрока). Это аналогично встроенному в игру редактору карт - если б не редактор, карты могли бы представлять из себя статичную 2D картинку/3D меш, но из-за редактора их нужно разбивать на тайлы/кубы. При этом ради высокой гибкости редактора карты мы жертвуем красотой цельной картинки, а для более продвинутого редактора придётся много чего изобретать с нуля...
В общем, подумай, так ли уж тут нужна гибкость? Я бы сделал так:
>class_name Damage extends Resource
>enum Type { NORMAL, FIRE, WATER, ICE, BLUNT, HEALING }
>@export var value: float
>@export var type: Type
>func deal_damage(target)...
>class_name Buff extends Resource
>@export var damage: Damage
>@export var time: float
>func tick(delta)...
>class_name Ability extends Resource # или Node...
>enum Target { POINT, ZONE }
>@export var point_cost: int = 1
>@export var target_type: Target
>@export var target_damage: Damage
>@export var target_buff: Array[Buff]
>@export var self_target: bool = false
>@export var self_damage: Damage
>@export var self_buff: Array[Buff]
>func use(at: Vector2) -> void:
>_ # 1. Уменьшаем число очков.
>_ # 2. Находим ближайшую цель/цели.
>_ # 3. Наносим урон целям и накладываем баффы.
>_ # 4. Наносим урон себе и накладываем баффы.
Этого должно хватить для 99% игр с "навыками". Геймплей зависит только от заданных значений, но даже их достаточно для высокой вариативности. Порядок действий задан фиксированным кодом, что гарантирует предсказуемость в будущем.
Из личного опыта, написать код в одном месте всегда проще, чем делать несколько независимых компонентов и потом их где-то склеивать, а потом искать и разбираться, где и почему что-то отваливается и не работает. При этом разделить связанный в одном месте код не так уж сложно, если он уже работает и его легко проверить (запустив сцену на выполнение). А в инди геймдеве важнее всего добиться рабочего (играбельного) прототипа любой ценой в кратчайшие сроки... Код прототипа не обязательно потом использовать где-либо. Важно только экспериментально доказать работоспособность возникших идей, а всё остальное решается рефакторингом. Иначе можно погрязнуть в оптимизации "самой гибкой в мире" системы и так и не добраться до играбельного прототипа желаемых идей. Конечно, если вся твоя идея игры не заключается в "сделать самую гибкую в мире систему навыков"...
В целом да, но для пущей гибкости компоненты наследуешь от белой ноды, и лепишь их прямо в дерево прямо как чайлды объектов, которым требуется композиция. В итоге получаешь и скорость разработки прототипа и будущий рефакторинг упрощается. Вот пример: https://www.youtube.com/watch?v=JJruVWtTXqA
> Может ли игрок сам (через GUI) составлять комбинации из этих действий?
Не через сам GUI, но определенным образом может, собрав модификаторы другого плана, допустим, раса персонажа игрока стала "очень крутой", и навыки должны начать работать немного по-другому, допустим, после каждого нанесения урона должен накладываться дебафф, все прямые нанесения урона наносят урон 2 раза по половине от начального, а любое лечение сверх максимального хп спавнит дополнительного союзника, либо, если он уже есть, увеличивает его хп, и т.д.
В плане концепции у игрока чаще всего будет мало навыков, а одновременно в одном бою из всех навыков он сможет использовать до 5-6, причём, слот навыка может заменять пассивка, поэтому ему должна быть доступна модификация навыков в той или иной степени, чтобы было возможным побеждать с 3-4 навыками или даже проходить игру со стартовыми способностями + прочие модификаторы
Про вариант с кодом в одном месте, мне кажется, будет сложнее делать какие-то модификации, допустим:
1) есть действие обычной атаки
2) есть действие, которое наносит урон N раз, где N - количество врагов, оно добавляет в очередь действий N действий обычной атаки
3) есть действие, которое заменяет все обычные атаки на наложение дебаффа
И допустим игрок получил навык с действием 2, после модифицировал навык действием 3, после чего действие 2 должно начать не наносить урон N раз, а накладывать дебафф N раз
мне кажется, сделав папку с кучей сцен, которые будут представлять определенные действия, и потом слепляя это в навыки, можно будет и быстрее понять, что навык из себя представляет, и модифицировать в процессе, и даже в дебаг режиме посмотреть, во что он будет превращаться с теми или иными модификаторами
В целом, в концепте есть некоторая поломка баланса игроком вроде the binding of isaac, но строиться будет не только на подбираемых предметах
>наследуешь от белой ноды
Это хорошо только для уникальных нод...
Не забывай, что у нод есть своя цена.
>>1034444
>допустим, после каждого нанесения урона должен накладываться дебафф, все прямые нанесения урона наносят урон 2 раза по половине от начального, а любое лечение сверх максимального хп спавнит дополнительного союзника
Ты хочешь ради этого менять структуру/состояние компонентов всех навыков персонажа, верно? Это выглядит неэффективно... Я бы добавил концепцию модификатора урона: навыки сами по себе никак не меняются, но к ним применяются доп. действия.
Тогда получается что-то вроде:
1. Навык генерирует урон по цели.
2. Урон передаётся вверх к владельцу.
3. Владелец добавляет к нему бонус расы.
4. Владелец отправляет урон назначенной цели.
Имхо, это лучше, чем как-то менять все навыки... Независимо от того, можно ли менять навыки.
>слот навыка может заменять пассивка
Слот в GUI ≠ слот в программной структуре объекта. Пассивные эффекты могут быть в другом месте...
>сложнее делать какие-то модификации
Речь шла о том, чтоб сделать ПРОТОТИП.
Вот ты сейчас можешь поиграть в свою игру? На компьютере, а не в своих фантазиях. Потому что на данный момент твоё описание выглядит как чистая фантазия "было бы круто давать бонус вампиризма вампиру, и чтоб каждая атака накладывала дебафф". Сложность геймдизайна в том, чтобы узнать, что из фантазий реально работает на пользу, а что лишь отвлекает от главной задачи и игрока, и разраба.
Конечно же, сделав гибкую систему навыков ты в будущем сможешь налепить любые навыки. Но тут ключевое слово "будущее", что может никогда и не наступить для твоей идеи игры... А вдруг ты потом обнаружишь, что всё фигня и достаточно лупить единственной оптимальной атакой? Потраченное на бесполезную разработку время уже не вернуть.
Короче, если ты ещё не сделал рабочий прототип, сфокусируйся на минимальном геймплее вроде:
- 1 герой со статичной аватаркой-затычкой;
- 2-3 типа врага со статичным спрайтом;
- 2-3 типа атаки, 2-3 типа дебаффа;
- 2-3 локации для навигации;
- конечная цель геймплея;
- базовые менюшечки.
Потом уже будешь ломать голову над тем, как это расширять и чем расширять интереснее всего. Даже минимальный геймплей луп задолбаешься делать...
Просто говорю по опыту, как тот, кто постоянно себе выдумывал какие-то расширяемые велосипеды, но в результате никак их ни к чему не применил и бросил. Потому что игра важнее каких-то мудрёных систем.
Официально рекомендуют группировать вокруг сцен:
https://docs.godotengine.org/en/stable/tutorials/best_practices/project_organization.html
>...the most common approach is to group assets as close to scenes as possible; when a project grows, it makes it more maintainable.
Под "ассетами" понимаются и скрипты тоже.
>делают в кучу из обучающих видосов
Видео пишут на скорую руку и в основном люди без реального опыта разработки. Как накидали - так и показывают. Поэтому всё в одно место свалено.
Я делаю примерно так:
>game - основная папка
>game/game.tscn + game.gd
>game/actors/player/player.tscn + player.gd
>game/actors/player/model/player_model.gltf
>game/actors/player/model/player_model.tscn (+ .gd)
>game/actors/player/model/mats/skin.png
>game/actors/player/model/mats/skin.tres
>game/actors/player/sound/...
>game/ui/menu/main.tscn + main.gd
>game/ui/logo/logo.tscn
>game/ui/theme/theme.tres
>game/music
>game/props - декорации
>game/world - карты/чанки, скайбокс/фон
>utils - скрипты и ресурсы, полезные много где
>utils/ui - разные генерализованные фичи UI
>test - что-то временное, сырые прототипы
>addons - для аддонов от других людей
И так далее.
>корежит, когда рядом с кодом валяется не код
Привыкай. Файл .tscn - это тоже код, только он не императивный, а декларативный (по типу HTML) - описывает, как сцена должна будет выглядеть. Ещё возможно сохранить GDScript прямо в .tscn, если это небольшой связывающий кусочек кода (там есть ограничения, но зачастую это не страшно).
В принципе, практически всё можно запаковать в единственный файл .tscn, но это будет неудобно и неэффективно (чем толще файл, тем сильнее лаги редактора при открытии, сохранении и т.д.). Но это полезно знать, т.к. иногда Godot пытается сохранить ресурсы неэффективно (особенно мешей касается - почему-то они у меня часто в .tscn залезают).
Алсо, чаще всего в Godot ты оперируешь сценами: загружаешь, вставляешь в дерево, удаляешь или заменяешь. Скрипты - это "расширение поведения" конкретных нод, из которых состоят сцены. Поэтому большинство скриптов принадлежит конкретным сохранённым в .tscn сценам, а не просто так. Но, разумеется, можно писать и скрипты-утилиты без конкретной связанной с ними сцены, если нужно.
Одно из преимуществ организации по папкам - в относительных путях. Вместо такого кода:
>load("res://game/actors/player/model/mats/skin2.tres")
Код в файле player_model.gd может использовать:
>load("mats/skin2.tres")
Этот путь будет работать даже при переносе папки.
Если пишешь код не на GDScript, то смотри сам. Как правило другие языки используют ради скорости выполнения, а она нужна только для определённых числодробительных систем. Такие системы лучше отделить от сцен в виде скриптов-утилит, ИМХО.
Собственно, основная задача GDScript - быть "клеем", связующим компоненты игры в единую систему. Это означает, что логичное место - вместе с контентом.
Я сейчас прочёл твой пост и придумал идею аддона для редактора. Аддон который при его активации над открытой сценой проверяет все ресурсы и предлагает сохранить отдельно все найденные вложенные. Либо автоматически сохраняет без вопросов, если настроить в конфиге политику именования.
Ладно, буду экспериментировать. То, что сцена тоже код, уже задумывался в качестве психологического компромиса, да и ковыряться в них ручками уже приходилось, спасибо глюкам. Так же задумывался, что редактор в случае переноса туда сюда удобнее будет использоваться, так как реструктурировать нужно лишь общюю директорюю payer например, а не scenes/player, src/player, resources/player отдельно например. Но это мелочи на моих хеловорд хуевинах. Как раз хотел понять как делают люди с большими достаточно проектами.
>рекомендуют группировать вокруг сцен
дык это база, основа в подобных движках. в итоге получается почти небинарное дерево aka SceneTree
> Ты хочешь ради этого менять структуру/состояние компонентов всех навыков персонажа, верно?
Всех активных навыков в данный момент (неактивных может быть больше, как колода карт и рука), при условии, что навыков всего будет максимум 5, не думаю, что это слишком переусложняет задачу
>> слот навыка может заменять пассивка
> Слот в GUI ≠ слот в программной структуре объекта
Да, я это написал к тому, что навыков мало, и может быть ещё меньше, это как в нойте при лимите в 4 палки вешать на одну одновременно и копание, и телепорт, и лечение
> 1. Навык генерирует урон по цели.
> 2. Урон передаётся вверх к владельцу.
> 3. Владелец добавляет к нему бонус расы.
> 4. Владелец отправляет урон назначенной цели.
Мне кажется, такое распыление плохо влияет на возможность модификации, даже чем-то простым, например:
- целевая атака становится случайной
- целевая атака становится атакой по всем врагам
- у атаки есть собственный дебафф, который складывается с доп. дебаффами сверху
- модификатор, от которого провоцируется активация навыка союзника
Если это всё добавлять сигналами или маркерами и передавать выше, придётся добавлять эти маркеры во все навыки, что превратится в жуткую мешанину, вроде как добавить ноду ещё одного действия или заменить одно действие на другое, выглядит не так сложно
> Вот ты сейчас можешь поиграть в свою игру?
Частично, сделаны герой, враг, система ходов, очки действия, "рука" навыков, и я как раз сделал навыки кодом и появилась проблема как с этим адекватно работать, если навык начнёт делать что-то большее, чем просто наносить урон одной цели, пусть даже просто начнёт наносить урон случайной цели, каждый раз вынимать навык из колоды и менять на другой выглядит неэффективно, тем более что придётся выдумывать, как эти навыки делить на подкатегории (наверное, проблема с этих "подкатегорий" и началась, лучше сделать категории на "действия", но не на "навыки", как контейнер "действий")
Я храню в отдельном каталоге scripts, потому что один скрипт может подключаться к разным сценам, наследоваться, быть классом, быть СИНГЛТОНОМ без сцены и так далее.
Пытался разделять несколько лет назад, в результате забил, уже лет 5 делаю скрипты рядом со своими сценами.
В самой навороченой игре (сложнее Хоппы) структура проекта такая
addons/ с 20 аддонов включая свои. менеджер камер, диалоги, время дня, погода, шлейфы, следы, шаги, растительность, террейн, водички, сиськи, диалоги, отладка
assets/
-characters/, там еще подпапки, enemies, player, animal и тд.
--skins/
--gear/ оружие и одежда
-env/ (здания, мебель пропсы деревья камни и тд) когда возможно засунуты в гридмапы.
-vehicles/ транспорт
-gui/, font/
audio/
components/ Сцены+скрипты всякие компоненты для геймплея. Поднимаемый, повреждаемый и т.д.
-actions/ всякие навыки персонажа, оружие
ai/ Сцены+скрипты ии врагов
vfx/ эффекты
scenes/ тут вся игра. ленюсь разбивать по папкам, пофиг они же обычно в дереве сцены. там есть main menu, options, уровни/подуровни,
shaders/
terrain/
textures/ с переключением между hi/low quality
sytems/ на самом деле еще десяток модулей которые не аддоны. Например контроллер персонажа, хелсбары, миникарта, компас, стриминг уровня, таргетинг/обводка целей, тачскрин джойтик, вертексная анимация, декали и тд
Тоже прикольно. Я велосипедист, думал мне аддоны могут пригодиться как часть системы. Разве что я пока в обучении до них не дошел и не выкупаю особо чем аддон отличается от любой другой папочки которую просто ctrlc ctrlv.
Зачастую (но не всегда) аддон содержит plugin.cfg в котором указан какой то тулскрипт, работающий внутри редактора.
>I found out, the hard way, that using tweens with fonts with outline works very bad on older phones - a frame taking 1,5 second to render.
>Although it seems like an easy and cheap way to achieve very nice effects, it turns out that the best way to do it is by using pictures with the same tween effect instead.
>cgeadas | 2020-03-26 16:27
1) Почему никто не сказал, когда спрашивал ИТТ?
2) Почему это до сих пор (Godot 4.3+) проблема?
3) Как делать красивый шрифт с анимацией?
>идею аддона для редактора
Было бы идеально иметь способ просканировать все имеющиеся сцены на наличие в них base64 картинок, записанных в Array мешей и прочей фигни, которую по хорошему лучше хранить в бинарных файлах. Все эти текстовые форматы хороши только когда их можно вручную просмотреть, а не 20 Мб магических чисел.
Я знаю, что есть бинарный формат .scn, но в случае странностей и ошибок его можно только из архива восстановить. Текстовые tscn всё же полезны...
>>1034617
>реструктурировать
А ещё удобнее переносить в новый проект. Если потребуется игра с чем-то, что уже было в старой - достаточно перенести одну папку, а не копаться в нескольких местах типа "ассеты/сцены/скрипты".
>>1034622
>бинарное дерево aka SceneTree
У бинарного только две ветки - левая и правая. Есть просто "дерево" - структура данных с произвольным количеством веток. Как вложенные Array/Dictionary.
Потому что конечно же каждый ИТТ твинит шрифты с аутлайном на старых андроидах. Каждый день этим занимаемся перед завтраком.
Я каждый раз, когда тут заходит диалог про разработку под могилки, говорю что могилки это лотерея. Там огромный зоопарк чипсетов и их версий, любой из которых запросто может не уметь любую банальную хуйню, даже на новых телефонах бюджетного сегмента. У меня одно время были отзывы в гуглплее вида "помогите, черный экран!!1", а я хуй знает почему, а потом оказалось что там какой-то нищий китайский чип не мог загрузить текстуру выше 512х512. В чипе в принципе отсутствует такой функционал.
А шрифты конкретно у меня твинятся на андроидах нормально. И на тех девайсах что я имею и в гугловском файербейсе с его кучей тестовых мобилок.
>возможность модификации
>если навык начнёт делать что-то большее
Есть понятие "преждевременная оптимизация", когда пытаются выжать миллисекунды почём зря, ухудшая читабельность и поддерживаемость кода. А есть... Не помню термин... Скажем, "чрезмерное планирование": пытаешься предусмотреть любые будущие варианты развития проекта и адаптироваться к ним заранее. Подобное планирование только замедляет работу.
Вот есть ECS, он типа "идеален" для игр, якобы даёт возможность "комбинировать всё со всем", но это аналогично языкам с динамической типизацией: запихнуть String можно куда угодно, но во многих ситуациях это приведёт к ошибкам или проблемам. Строгая типизация - это страховочная система, чтоб засовывать что надо и куда надо, а не куда попало. Классовая система объектов - тоже страховка от незапланированных смешиваний в системе, т.к. все данные и код делятся на конкретные группы/типы.
Хочу сказать, что "сложность незапланированной модификации в будущем" - не всегда недостаток системы. Твой код должен быть понятным, чтобы снизилась сложность модификации. Но если ты буквально что угодно с чем угодно соединяешь, понятность взаимодействия частей кода снизится.
Вот интересная статья на эту тему:
https://habr.com/ru/articles/568216/
Нужно избегать "destructive decoupling".
В общем. Какая-то гибкость нужна, типа менеджера навыков. Но избыточная "гибкость" превращается в непонятную кашу непонятно чего. Как спагетти-код. Спагетти можно распутать, пройдя по ссылкам, а деструктивная развязка переносит "спагетти" во взаимодействие в рантайме, что ещё сложнее...
>навыков всего будет максимум 5
Проблема может возникнуть из-за смены состояния объекта несколько раз. Скажем, был урон 100, далее:
- мод 1 уменьшает на 90%
- мод 2 добавляет 50 очков
- мод 3 умножает на 2
Выходит урон в 120. Но если поменять порядок, то получается уже 30 или 25. Так какой порядок считать правильным? И как игрок поймёт, в каком порядке складываются модификации на его оружии/навыке? Нужно убедиться, что порядок следует формуле, а не зависит от какого-то случайного фактора.
Я сначала неправильно выразился. Проблема не в технической "эффективности", наоборот, поменять множители один раз эффективнее по скорости и по расходу памяти. Но порядок действий может быть неправильным и отследить это будет тяжело.
Ладно. Я тоже чрезмерно всё планирую...
> Почему никто не сказал
Писали неоднократно. Шрифт работает так практически везде, он собирает команды на рисование вектора и всяких хинтингов и кеширует нарисованый атлас. При изменении размера шрифта все перегенеривается. Про аутлайн не в курсе.
>Что делать
Попробуй галочку SDF шрифт. Хотя может на мобилке это медленнее.
Можно попробовать аутлайн шейдер. Он же будет искать закрашенные пиксели и расширять зону.
Если вопрос в аутлайне, можно сделать псевдаутлайн, вывести на фоне текст еще раз и скейлить его через scale, а не менять размер.
Можно еще что то придумать. Отрендерить нужные размеры текстов и анимировать как флипбук
Мне вот сложно нащупать эту середину. С одной стороны мне хочется убивать, когда я вижу на похуй накиданный код. Типа да, он простой и даже понятный, но то что он не бажит вот прям здесь и сейчас, запускает и не рушится это пиздец какая удача в 99% случаев, а если расширять нужно ctrl+a - delete сразу делать. С другой слишком гибко и четко и даже без багов - это для точно такой же херни, что решает первый кусок говна придется потратить х100 времени. Зато будет непробиваемо и идеально расширяемо, правда никому не нужно, кроме моего перфекционизма. В целом таким страдаю в макакерстве своем, не только в гд. В игре одной захуярил скриптовый язык транзакционный, полностью безопасный, чтобы контентные негры могли сами скрипты писать к квестам/диалогам и тд. Итог - нихуя они не писали, хотя язык был намеренно проще некуда специально под эту задачу. Не пригодился, заставили меня самого все делать. Вот такой вот я планировщик ебанат.
>Потому что конечно же каждый ИТТ твинит шрифты с аутлайном на старых андроидах. Каждый день этим занимаемся перед завтраком.
Пошутил так пошутил, я аж улыбнулся))) Шрифты с обводочкой - база, твин гуя - база, старый андроид - работает и не жалуется... Или ты только статичные пиксельные шрифты на новые флагманы делаешь?
>>1034682
>При изменении размера шрифта
Размер шрифта в Label (или RichTextLabel) точно не менялся. Менялся только PanelContainer в предках. Неужели это вызывает рендеринг шрифта заново?
Короч, идея была такой: квадратное окошко быстро анимируется в стороны и на нём печатается текст... Сначала вроде норм было, а потом залагало всё.
>Попробуй галочку SDF шрифт.
Да наверняка будет ухудшать рендеринг... Пожалуй, нужно проверить, не включил ли я его случайно. Т.к. перетаскивал шрифт из одного проекта в другой...
Возможно, это просто шрифт такой жирный... Очень сложно найти красивый, открытый шрифт с полной поддержкой кириллицы и хорошей читаемостью.
>Можно еще что то придумать
Да это понятно. Просто проект уровня hello world, ВНЕЗАПНО вызывающий лаги шторки Android из-за нагрузки на GPU, как-то не очень вдохновляет. Если говорить прямо, я разочаровался и впал в депру...
Попробую что-нибудь сделать, авось получится.
Телефон среднего уровня, но осени 2019...
Таких тонкостей не припомню, что панель контейнер меняет, разве не просто scale? что именно ты твинишь то? Попробуй без контейнера.
а еще я бы для мобилки делал на 3.6
> Не забывай, что у нод есть своя цена.
У белых нод (Node) минимальная цена, неотличимая от того же ресурса.
да, я знаю, что они существуют, но мне интересно мнение живого человека, а не просто знать о наличие такого софта
Делал несколько сетевых на сокетах, заебись, пользовались целые организации.
Делал морду для чатгпт, это подойдет? Заюзал изза легчайшего гуя только, логика питонячьим сервисом.
>>1034738
Так а с точки зрения разраба, насколько оно было приятно? Не возникало мысли дропнуть и сделать обычным способом на каком-нибудь другом языке?
У меня нет. Годот и взял потому что гуи в большинстве случаев просто ужасающее говно на других языках. Годнота еще электрон в плане разработки и внешки, но как же мерзотно он лагает мамамия. Так что взял и не жалею. Даже прикольное ощущение, что пока ты пилишь гуй твой инструмент по сути может предложить мощ целого игрового движка в любой момент при желании, а не только кнопочки с дизайном из виндоус95, как какойнибудь ткинтер.
делал пикрил лол, активно пользуюсь
записываешь название, прога сохраняет это с текущей датой как списочек в файл, при следующем открытии загружает этот файл, если 2 раза кликнуть на крестик удаляет запись и сохраняет изменения
первое поделие в годоте, я немного мобильную разработку на kotlin ковырял перед этим, в целом ни там, ни там не душно интерфейс делать, достаточно удобно, разве что в мобке надо ещё поворот экрана учитывать
В целом было максимально комфортно. Нет, не возникало мысли дропнуть. На других языках делал, там куча своих проблем с графоном. Тут взял и работает.
В гуе не все можно сделать из коробки, ну так это игровой движок а не симулятор html. Что то там всем тредом не могли выставить, внешний марджин вокруг текста в кнопке вроде бы, и многопроходные шейдеры на те же кнопки. Но это объявляется нинужно и двигаешься дальше.
Бонусом было что в приложении использовались 3д элементы. Витуберский аватар как пример похожего с захватом с камеры.
Делал гуевую программу для обучения школоты. Получилось быстро-просто, всегда бы так.
> электрон в плане разработки и внешки, но как же мерзотно он лагает мамамия
Падажжи, но ведь МСКоде написан на электроне, и он вполне себе шустр. Может ты делал это неправильно?
Я делал конструктор диалогов в стиле древнего движка "аврора" (невервинтер, первый ведьмак), планировался именно отдельный инструмент, а не аддон, но потом появился диалоджик, который обошёл меня во всём, я словил демотивацию и забросил. Но пока я эту приложуху делал, проблем не испытывал. Любой элемент управления легко конструируется композицией. У меня получались выпадающие списки с элементами вводимыми на лету в диалоговые поля и т.п. И всё это на трёшке. А сегодня в четвёрке с функциями первого порядка будет еще проще. Вплоть до реализации паттерна MVVM.
А предметов-то будет, не больше десятка. Ну и короче оно адекватно будет через match менять переменные или это говняк?
Кстати, какие фишки редактора помогают в 3д? Я например часто жму F - центрирует камеру на выбранном объекте. Альт + правый клик - показывает список объектов под кликом, полезно когда объекты навалены кучей.
Я делал это очень давно. И вскод в молодости лагал как десяток иде разом. До него еще кое кто был, не выжил. Сейчас да, уже не заметно почти, говорят когда оптимизируешь хуевину десяток лет неограниченными ресурсами такое мождет произойти.
>Когда я вызываю по ид предмет из массив, то я меняю его число только в массиве, а не не на самой @export переменной
Че он несет? Просто экспортируй сам массив, зачем тебе отдельные переменные?
@export var inventory : Array[int] = [...]
И все, и больше ничего
func change_item(id, value):
____inventory[ID] += value
И больше ничего
> Короче нужно сделать "инвентарь" самый базовый.
Без сарказма и без троллинга инвентарь это
> var inventory := []
список. Просто список. А всё остальное (что ты хочешь на самом деле) это обёртки для работы с этим списком.
А теперь, зная это, подумай и напиши, что ты хочешь конкретно, именно.
>приложения на годоте
Пробовал делать несколько утилит, ничего серьёзного. Godot с GDScript удобен и всё такое, но очень тяжёлый. Раньше активно кодил в Delphi и Lazarus, до сих пор пользуюсь одной своей программой на Lazarus под Windows. Думал переделать её на Godot, но увидел:
- оперативной памяти Godot тратит раз в 10 больше;
- фоновая нагрузка на CPU выше даже с костылями;
- тратится видеопамять, плохо на фоне игр держать;
- сравнительно дольше перезапуск (2~3 секунды).
Так что мотивация как-то быстро улетучилась, лол.
В общем, Godot очень хорош для больших программ наподобие какого-нибудь Blender, где очень много UI, сложные операции и программа не держится на фоне круглосуточно в качестве мини-помощника/утилиты.
Для мелких утилит Godot равен Electron/Python/etc - прожирает ресурсы компа сильнее твоего кода, лол.
Собственно, ожидаемо. Этот ж ИГРОВОЙ движок.
Отдельно замечу, что прикладным программам по определению не нужен красивый GUI, поэтому выше описанная критика "окно как в Win95" некорректна. Прикладная программа - не игрушка, и ей главное выполнять работу точно и в срок, с минимальными затратами критических ресурсов. Красота GUI на последнем месте, лишь бы все кнопки работали. Наоборот, чем "красивее" GUI, тем хуже, ибо этот GUI растрачивает ресурсы, необходимые пользователю.
Расскажи свой последний абзац в desktop ricing тредах. Сам я по ним не угораю, но когда-то написал опенсорную консольную программку, и пару раз ее видел на скринах анонов на форче, реддите, и даже на дваче, лол. Причем я уверен что как программа она им была не нужна, просто выглядела прикольно.
Именно поэтому хочется лёгкую имплементацию ГДСкрипта, да хоть в лазарусе/дельфи как скрипт-компонент. Но лучше как отдельный компилятор. Чтобы да.
>desktop ricing
>просто выглядела прикольно
Мы обсуждали прикладное ПО, а не вкусы г@ймеров.
Ещё скажи, что RGB подсветочка суперпопулярна в офисных ПК больниц, где без RGB радужного CPU вентилятора врачи не могут работать с больными - отказываются работать на "скучном" компьютере.
В офисных ПК кастомизация ОС обычно запрещена. Пользователь ограничен необходимыми для работы программами и доступом к локальной сети офиса. Аналогично с ПК в школьных кабинетах, классах.
Алсо часть прикладных программ требуется работа в реальном времени. Не как "игры реального времени", а по-настоящему, чтоб ничто не могло съесть 10 мс в неожиданный момент времени. Тут не до красоты.
>>1034934
>хочется лёгкую имплементацию ГДСкрипта
По идее, самое тяжёлое в GDScript - динамическая типизация. Но от неё не будут избавляться... Как и переделывать GDScript в язык общего назначения.
>как отдельный компилятор
Даже встроенный был бы хорош... Не в байт-код, а напрямую в машинный код или через какой-то C... Вариантов много, но ничего так и не выбрали (?).
>По идее, самое тяжёлое в GDScript - динамическая типизация. Но от неё не будут избавляться... Как и переделывать GDScript в язык общего назначения.
Самое тяжёлое во всём годоте - тип Variant, он может быть чем угодно, включая любой класс годота, любая даже типизированная переменная это Variant, конкретно в gdscript почти всё делает одна огромная функция, https://github.com/godotengine/godot/blob/master/modules/gdscript/gdscript_vm.cpp
Можно сказать что это и есть динамическая типизация, но не только. Там наверняка какой то косяк в реализации, потому что есть другие примеры языков без типизации (js, php) которые обгонят gdscript очень сильно и будут потреблять в разы меньше памяти. Надеюсь репозиторий годота когда нибудь посетит гуру написания парсеров и интерпретаторов и хорошо им там наоптимизирует.
>примеры языков без типизации (js, php)
Они всё равно сильно отстают от компилируемых.
>гуру написания парсеров и интерпретаторов
Чем пытаться выжать всё из интерпретатора, лучше разработать/найти компилятор с оптимизациями...
Алсо, компиляция не обязана быть медленной. Вот Pascal компилируется быстро, и хоть и отстаёт от C, преимущество быстрой компиляции очевидно: раз нажал F9 и уже видишь на экране свою программу.
Какой то упитанный пост, ну или ты реально не понимаешь, что js и php были ОЧЕ медленным языками, просто их движки переписывались по восемь раз миллионными мегакорпорациями.
>есть другие примеры языков без типизации (js, php) которые обгонят
Ну ты сравнил. JS - мегаоптимизированный язык, в реализации которого влили кучу бабла мегакорпорации. А GDScript по твоей же ссылке пилится по сути одним человеком - vnen. Остальные только варнинги подпиливают да прочую мелочевку. Достаточно git blame глянуть. Для оптимизаций там поле непаханое.
Чо только растоидоры не высрут, лишь бы загнать народ на раст.
>Они всё равно сильно отстают от компилируемых.
Да, но я ж не сравниваю с компилируемыми
>Чем пытаться выжать всё из интерпретатора, лучше разработать/найти компилятор с оптимизациями...
Да, но они не откажутся от интерпретации, мне это очевидно
>Вот Pascal компилируется быстро
Опять компиляция, я про интерпретацию.
>>1035016
Твой пост упитанный, bun сколько раз переписывался, что с бета версии быстрее существующих переписанных восемь миллионов раз движков?
>>1035019
привел пример интерпретируемых языков которые очень быстро работают, питон специально не упоминаю т.к. вся его скорость обеспечена вызовом функций из нативных библиотек, в принципе как и в GDScript, но тут можно было докопаться.
Описываешь предмет инвентаря без количества:
>class_name ItemData extends Resource
>@export var item_name: StringName
>@export_multiline var description: String
>@export var picture: Texture
>@export var max_amount: int
И т.д. по необходимости. Потом сам инвентарь:
>class_name Inventory extends Resource
>## Удалять нули из списка вещей.
>@export var drop_zeroes: bool
>## Количество вещей в инвентаре.
>@export var store: Dictionary[ItemData, int]
>## Возможные вещи (заполнить заранее!).
>@export var items: Dictionary[StringName, ItemData]
>func add(id: StringName, amount: int) -> void:
>_ var item := items[id]
>_ if item not in store: store[item] = amount
>_ else: store[item] += amount
>_ store[item] = clampi(store[item], 0, item.max_amount)
>_ if drop_zeroes and store[item] == 0: store.erase(item)
Ну и можно int обернуть в ссылочный тип:
>class_name ItemAmount extends Resource
>@export var amount: int
Тогда код немного изменится:
>@export var store: Dictionary[ItemData, ItemAmount]
>...else: store[item].amount += amount
И т.д. Это если тебе обязательно ссылочки иметь.
Ну или объединить ItemData и ItemAmount...
>Dictionary[ItemData...
Что-то я тут перемудрил, не нужно так делать.
Делай так, как удобнее будет в редакторе править...
Питон кстати в последних версиях неплохо ускоряют, и над избавлением от гила работают, наканецта. Как и говорилось, ускорение реализуется вливанием мегабабла.
>Как и говорилось, ускорение реализуется вливанием мегабабла.
Если б всё дело было в бабле, мы бы не сидели на Godot, не?..
Чисто по сырой ничем не прикрытой мощи Godot лидирует...
Сидим тут вопреки такой себе производительности гдскрипта, а не ради нее. Ну а кому надо шустро пишут в годоте на плюсах.
Годот это подруга из молодости, с которой ты бухаешь и трахаешься по фану, а она еще и подкармливает бутербродиками. А юнька с уе - это корпоратская фемдом холодная мразь с флюгегехаймен в одной руке и оплатой в другой.
А то я смотрю на современные процессоры, и там iGPU по мощности либо почти как 750 Ti (Intel), либо даже мощнее (AMD). Моей 750 Ti мне сейчас хватает практически на всё, кроме нейронок (больше 1.5 миллиардов параметров просто не влезает в VRAM), поэтому гнаться за новой пока не планирую. Вот думаю, если собрать/купить ПК (или мини-ПК) на процессоре с iGPU, я ж могу вообще без дискретной карты обойтись и во все свои игры играть как раньше... В прошлом я довольно много старых игр попробовал на 2-ядерном 1 ГГц мобильном процессоре с iGPU от AMD и всё удивительно хорошо работало, но то старые игры, никакого Vulkan тогда не было.
В общем, хорошо ли работает Godot на современных встройках? Плюс-минус как на 750 Ti, да?
Ryzen AI Max+ 395 по встроенной графике примерно между RTX 3060 и RTX 3060 Ti, лол. Получается на 350% мощнее моей выделенной видеокарты. А это ведь мобильный процессор, 55 ватт... Но остаётся вопрос с драйверами. В тредах по нейронкам я вычитал, что Vulkan имеет какие-то проблемы с выделением памяти на iGPU под Windows. Впрочем, там они пытались задействовать все 128 Гб доступной RAM, а Vulkan почему-то не может больше 32 Гб...
Читая отзывы к железу осознаёшь, насколько люди зажрались... Если бы не новые наборы инструкций (SSE, AVX) и доступ к локальным нейронкам типа LLM, я бы продолжил сидеть на процессоре 2007 года ещё, наверное, пару десятков лет, или пока что-нибудь не накроется в материнке. Не представляю, на что можно жаловаться в >16-ядерных монстрах с производительностью одного ядра раз в десять больше достаточной... Понапишут своих "гениальных" программ на Python, а потом жалуются на процессор...
Лень все читать, скажу что сделал 2д игру на трешке на ноуте 2012 года с интеловской встройкой, полет нормальный, до сих пор на итче качают. Чего там в четверке хз. Ну и смотря что ты делать собираешься, 2д, 3д, уровень детализации, и тд. Но я спать уже.
Просто скачай, накидай примерный проект из готовых ассетов, или запусти готовое годотовское демо, и посмотри.
запускал 3д шеб игру на ноуте ~2012 года, все работало в шисят фпс
но там была микро-игра в 2 экрана
>Да
Пизда.
Ладно, спасибо, присаживаюсь тогда к вам. Надеюсь не наебали.
Посиди тут пока сам в тишине. Все ушли на ТВГ. Покормим тебя через 2 недели.
>экспортнуть сразу
В теории да, можно всё разу, но:
>на пекарню
Легче всего. Нужно только скачать export template. Собственный шаблон экспорта редко нужен на ПК - стандартные покрывают 99.99% возможных игр.
>на ведро
Нужно скачать OpenJDK и Android SDK и создать собственный ключ для подписи APK, потом - легко. Однако, для оптимизации под мобилки и каких-то дополнительных фич потребуется собирать всё из исходников - это немного сложнее, но нормально.
>на айфон
Честно, не пробовал, но Apple - анально огороженная платформа, требующая конпелировать iOS аппы на компьютере с macOS и Xcode, иначе они твоё дерьмо откажутся принимать в свой магазин говна. В общем, отвратительная платформа, что-то уровня соснолей - покупается лохами для своих мелких лошков, ибо в компьютерах они не шарят и учиться не хотят. Лучше просидеть всю жизнь на винде, чем мараться об мак.
Подробнее про экспорт читать тут:
https://docs.godotengine.org/en/stable/tutorials/export/index.html
Справдливости ради макос лучше винды, а макбук лучше дженерик ноутов. Как и айфон лучше андроида в среднем по больнице. Но сама компания где-то между размазанным говном на тарелке и конторой замечательных людей в виде ркн находится, это все портит.
>макбук лучше дженерик ноутов
Макбук Про 2017 это худший ноутбук, которым я когда-либо владел за последние двадцать лет. Залипающие клавиши (некоторые буковки печатаются по два раза за нажатие), стертые за год надписи на клавишах как на самых дешевых клавиатурах с алиэкспресса, пластик на клавишах полируется и перестаёт быть матовым за тот же год (выглядит просто ублюдочно), пиратская винда поставленная параллельно стартовал быстрее, чем макось, шлейф соединения дисплея перетирается от открывания за тот же год и дисплей просто перестает работать (у проблемы даже официальное название есть, лол, flexgate, ремонт у официалов 600 евро). Ты не встретишь таких проблем ни у одного ноутбука даже за 100 баксов, а макбукокал стоил почти 2к евро. Эпплодауны умалчивают об этом, чтобы другие купились, как я например.
Никому не советую брать макбуки, даже если лишние деньги появятся. Это мусор, а не техника.
>макос лучше винды, а макбук лучше дженерик
Именно поэтому на макбуки устанавливают Винду?
>айфон лучше андроида в среднем по больнице
Не бери звонилки за 1.5 т.р., если ты хочешь играть.
Android можно установить практически куда угодно, потому что это Linux с нескучным рабочим столом. Естественно, что это ведёт к бюджетным телефонам. Однако не всем людям нужен игровой смартфон или мессенджеры, браузерные приложения и подобное.
Просто игнорируй ньюфагов, купивших звонилку за стоимость двух походов за фастфудом, но при этом планирующих играть в 3D онлайн шутер с 60+ фпс... Покупать что-то в твоей игре они всё равно не будут.
За то, что назвал их хуже ркн? Сколько же нефти отсыпают за похвалу пидорасам тогда?
За похвалу - Big Mac. Как Mac, но большой.
>jai
>Jonathan Blow programming language
>велосипедим ЯП чтобы запилить сокобан
Идейное духовенство любителей переписывать архитектуру мультиплеерно-анти-антипаттерных кнопок ИТТ.
У него весь канал базируется на стримах какого-нибудь ебанутого языка или ебанутой логики на стандартном языке, так что твой аргумент тут мимо кассы.
>двумя if'ами кодит баунс квадрата от границ
Т.к. пишет хэллоу ворлд на языке без библиотек.
>подключали физику с коллизиями чтобы...
Чтобы поле могло быть любой формы.
>>1035716
Наоборот, сокобан - это тест компилятора.
https://jai.community/t/overview-of-jai/128
Любопытно, что он считает себя гением и трясётся:
>Compiler is currently proprietary
>Licensing to prevent embrace, extend, extinguish
Но даже не знает БАЗЫ велосипедокомпиляторов:
>creating commercial video game to test compiler
>will not be self-hosting the compiler in the near future
Все базированные языки компилируют компилятор.
https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
Если компилятор не компилирует сам себя, это фейл.
Ну а что по самому языку?
>Imperative, general purpose
>Statically, strongly typed
>Inline Assembly (лол)
>SIMD operations must be hand optimized
Т.е. оптимизируйте сами. На ассемблере. А ещё:
>No constructors or destructors
>No virtual functions
>No object oriented inheritance hierarchies
>No incremental rebuilds (т.е. ВСЁ собирается с нуля)
>No reference types (т.е. ВСЕ данные идут через стек)
>No array programming (т.е. нет "array.map(func)")
>No dot calls (т.е. нет "объект.метод(аргумент)")
Т.е. игры предлагается делать как в 1980?
И на десерт:
>started complier in 2014 to replace C++ in gamedev
Больше 10 лет ковыряет. Проект уровня TempleOS.
А по синтаксису это очередная копия C без плюсов.
Классический NIH-синдром в терминальной стадии.
Спасибо за подробный разбор. Аж жалко стало чела. Это реально болезнь какая-то.
>Все базированные языки компилируют компилятор.
Даже я это знал, просто потому что прикольный факт такой. Хотя в языкописательстве я никто.
>No reference types (т.е. ВСЕ данные идут через стек)
Вообще никакой связи. Reference это языковая конструкция, а не имплементационная деталь. Наприер в c++ reference это подвид указателя, но с дополнительными ограничениями наложенными языком (не может быть null, отслеживание типа, кто им пользуется и т.д)
Это абсолютно опциональная вещь, поскольку требует просто большого количества рутинной работы (написать все либы, которые могут быть не нужны для разработки игры).
Так он аутист, в смысле ирл. Высрал 1 пазл за всю жизнь, который всё равно пришлось оптимизировать Кейси Муратори, но собрал вокруг себя сообщество нитакусиков которые его боготворят.
>>1035822
Может себе позволить хуи пинать. На прошлых играх заработал на пару жизней вперед. Но как персонаж забавный, думаю через пару лет окончательно слетит с катушек и повторит историю Пирата и других поехавших кумиров.
Да, согласен, перепутал немного. Просто с моей т.з. практической разницы между pointer и reference не существует. Это просто "ссылка на участок памяти". Непонятно, что имели в виду под "no reference type". Получается, нельзя класть ссылку в переменную?
Если рассмотреть абстрактный пример:
>var number: Integer := 0 # "value type"
>var reference: Pointer := @number # "reference type"
Здесь "reference" хранит ссылку на "number", но по определению "ссылкой" (pointer) является "@x", а вот "reference" имеет тип "Pointer" = "reference type". Нет? Получается, что в Jai не существует типа "Pointer", но допускается использовать запись типа "@variable"? Непонятно, зачем вводить подобные ограничения.
Меня всегда путали все эти ссылки/указатели... Щас попытался поискать, и LLM помощник тоже путается.
>>1035837
>абсолютно опциональная вещь
Если твой компилятор не может скомпилировать компилятор, является ли он Тьюринг-полным? А то развелось тут "HTML программистов", понимаете.
Если серьёзно, написание компилятора на своём собственном языке позволяет протестировать язык, сэкономив на переключении между своим языком и посторонним языком, т.е. работать в одной среде. Разрабатывая Sokoban ты не работаешь над своим компилятором, хоть и тестируешь язык. Работая над компилятором на своём языке ты одновременно его разрабатываешь и тестируешь, не так ли? Поэтому бутстрапинг компилятора - база велосипедистов.
>большого количества рутинной работы
Ага, а ты как хотел? Изобрести язык без работы?
>написать все либы, которые могут быть не нужны
Во-первых, с большой вероятностью будут нужны.
Во-вторых, если очень лень - можно динамически линковаться с библиотеками на других языках. Или динамическая линковка для игр на новом языке не требуется? Будешь и физический 3D движок с нуля изобретать или всё-таки подключишь как DLL?
Но суть в том, что чем раньше ты начинаешь делать компилятор на своём языке, тем проще будет потом.
>>1035856
Да пусть делает, что хочет. Как будто мы тут игры разрабатываем, лол. Каждый развлекается как ему нравится... Кто-то вот языки изобретает просто так.
>Высрал 1 пазл за всю жизнь
Не 1, а 2. В остальном без возражений.
Хотя, как по мне, побольше бы таких аутистов, мир был бы добрее.
>>1035881
>Меня всегда путали все эти ссылки/указатели
Меня раньше тоже. А теперь освоил цпп и преисполнился.
Я написал свой ответ на основании наблюдений за несколькими разрабатывающимися языками, например Zig стал self hosted только через 6 лет после создания. И это реально чисто работа только для этой работы. Язык там особо не испытывается, там обычно портянки однотипных свитчей. Это отдельная деятельность, писать все эти парсеры.
>портянки однотипных свитчей
Лол. А на C++ эти же портянки писать не будешь? Или разработчик языка только меняет обои на нескучные, создавая "новый язык" копипастой существующего?
Посмотрел Zig - опять какой-то клон C. Ну и зачем?..
Форт-машину лучше напишите. Можно на GDScript.
>bun сколько раз переписывался,
Сходил посмотреть в вики
Bun uses WebKit's JavaScriptCore as the JavaScript engine
JavaScriptCore is originally derived from KDE's JavaScript engine (KJS) library
Since forking from KJS and PCRE, JavaScriptCore has been improved
On June 2, 2008, the WebKit project announced they rewrote JavaScriptCore
An optimizing just-in-time (JIT) compiler named FTL was announced on May 13, 2014.
4 раза получается. В правильно поставленном вопросе - половина ответа!
А я про с++ ничего и не писал. Я писал про то что "проверка" языка делается написанием разных хитрых языковых конструкций, а в компиляторе им обычно места и нет, это просто такой "библиотекарь" типа написано это - подставляем это.
> Zig - опять какой-то клон C.
На замену C (не с++), потому что у того слишком уж все устаревшее, начиная с макросов и отсутствия перегрузок функций. И RAII.
Так и не смог найти нормального туториала по мобайл гейм девелопменту на годоте, со встройкой рекламы, оплаты етц на обе мобильные платформы. Если есть кто итт знающий, подскажите плз.
Ты геймдевить вообще умеешь? Сколько игр сделал? Если нет, то
>со встройкой рекламы, оплаты етц на обе мобильные платформы
тебе пока рано делать, попробуй сначала просто игру смастерить.
Для встраивания сервисов Google Play/Android есть это:
https://godotengine.org/asset-library/asset?filter=google
https://godotengine.org/asset-library/asset?filter=android
Для iOS: https://godotengine.org/asset-library/asset?filter=ios
Алсо, если ты это ради бабла, то без бюджета ничего не выйдет.
На мобилках зарабатывает тот, у кого уже есть деньги на рекламу.
>а еще я бы для мобилки делал на 3.6
Сделал тест 2D анимации на Godot 3.6.1. CPU 14%, GPU 7%, вроде нормально, но я ещё не добавил ни шрифт, ни взаимодействия. И как же всё-таки не хочется что-то делать снова на 3.x... Это такой сильный даунгрейд и редактора, и GDScript. Когда я переходил с 3.4/3.5 на 4.0+, мне казалось, что практически ничего не поменялось или поменялось в худшую сторону. Но теперь понимаю, что прогресс в юзабилити редактора всё-таки был...
И без опыта, и чтобы убийца гта и майнкрафта в одном флаконе. Еще и шобы на нинтедно свищ 2. И санкции чтобы мы обошли для тебя.
Просто сделай хоть какую-нибудь базовую игру и выложи ее куда-нибудь типа итча. Тебе этого задания хватит на полгода.
Решил эту проблему не переходя на четверку. Но очень хочется. Вы там со своими фичами совсем охуели, а сижу тут, как фуфел, допиливаю.
Он, видать, кобанчик - заработать хочет. Ему некогда. Подскочил, понимаете, чтобы по-быстрому налутать баблишка с детишек, а тут туториалы не находятся - непорядок, нужно срочно искать план Б, иначе конец.
>>1036244
Дааа... Честно, не понимаю, зачем Godot'у вся эта "монолитность". Бамп мажорной версии был из-за рендеринга в основном: GLES2 дропнули и GLES3 переделали с нуля (с ошибками), сделали Vulkan... Собственно, почему нельзя вынести рендеринг в независимый от ядра движка модуль? Чтобы кому необходимо, подключал то, что ему необходимо. И пользовался актуальной версией GUI + GDScript. Аргументируют производительностью, но на мой субъективный взгляд, монолит весом 150 Мб будет медленным по определению... DLLки существуют с прошлого века, их наверяка уже оптимизировали.
У меня давно была мечта сделать "Лего"-движок, кастомизируемый без компиляции. Просто накидал модулей в виде DLLок в папку и всё работает. Вроде некоторые игры имеют под два десятка DLL и всё нормально работает, не? GDNative/GDExtension вроде подобное позволяет сделать с аддонами, но аддоны добавляются к жирному монолитному ядру... Можно попробовать раздробить это ядро, но я не шарю в программировании на C++ в достаточной мере...
Кагбэ, насколько мне известно (собирал свои DLL), производительность снижается только в момент подключения, когда ОС ищет и соединяет все эти невидимые "провода" между разными функциями. Непосредственно рантайм вроде бы не страдает.
Поискал в интернете:
https://stackoverflow.com/questions/9456635/
>Unless the function is very small (so it gets inlined otherwise), using a DLL has no difference whatsoever on the performance (aside from the fact that loading a DLL does increase the startup time of your application.) Large, performance-critical applications use DLLs (for instance the Intel Math library.) There are minor penalties if the compiler cannot do whole-program optimization, but these are very small differences which usually don't matter.
Думаю, стоит попробовать раздробить Godot на DLL.
Бонус: это может помочь удалить 3D без компиляции. Большинство игр всё равно 2D от зелёных новичков. Экспортные шаблоны нужно заново компилировать только на платформах типа мобильных, где один APK (теоретически, Android поддерживает что-то типа DLL; практически, для игрового движка это невыгодно).
Маршалинг. Чтобы вызвать функцию из другого модуля, надо создать структуру, туда записать аргументы, контекст, передать. Если аргументы проходят через цепочку функций, умножается. Вот на этом производительность и съедается. Скомпилированный монолит будет оптимизирован компилятором так, что там целые цепочки вызовов будут выкинуты.
>>1036533
Хуя проекции. Я попросил туториал для вашего движка на мобильные платформы, а у вас уже гта и тд. Если это не тред изучения Godot, то тогда другое дело.
Эм, я не понимаю, о чём ты говоришь... Объекты ведь остаются без изменений, вся разрица в том, когда код получает необходимые ему ссылки для прыжков.
Сразу скажу, мой основной опыт компилируемых ЯП состоит из вариантов Pascal; я понимаю, что у C/C++ немного другие функции, но в общем и целом всё это сводится к тому, как работает ОС и микропроцессор.
Если мы вызываем функцию в своём модуле, мы:
1. Кладём свои аргументы на стек.
2. Кладём на стек адрес возврата.
3. Сохраняем состояние регистров.
4. Прыгаем по адресу функции.
5. Выполняем код функции.
6. Сохраняем результат на стек.
7. Прыгаем по адресу возврата.
8. Восстанавливаем регистры.
Все адреса заложены в нашем коде компилятором. Процессоры оптимизированы на то, чтобы делать операции перехода максимально дешёвыми. Даже специальные ассемблерные инструкции имеются. Т.е. описывать этот процесс дольше, чем его выполнить.
Если мы подключили динамическую библиотеку, то выполнение функции ничем не отличается, кроме отсутствующих адресов. Эти адреса записываются автоматически функциями ОС, которая находит нам подходящую DLL и соединяет все адреса как нужно. Затраты тут только в момент подключения DLL - т.е. перезапись адресов теми, которые определила ОС.
Предположим, что вместо чистой функции (функция, выполняющаяся без побочных эффектов) мы имеем конструкцию, меняющую данные соседнего модуля напрямую, т.е. создающую побочный эффект. Тогда достаточно передать ссылку на адрес в памяти, где требуется создать этот побочный эффект. И даже не обязательно передавать её каждый раз, достаточно сохранить её в области памяти конкретного модуля.
В общем, я не вижу, где тут усложнение вызовов... Производительность теряется только если ты мог бы скопипастить код прямо в точку его вызова, но это из разряда однострочных функций типа "return a + b", что чрезвычайно редкая ситуация в проектах чуть выше банальных "hello world". Если компилятор начнёт всё подряд копипастить, EXE быстро раздует до гигабайт. Совершенно без прыжков в коде не обойтись, это невозможно чисто физически для процессора.
Проблема подключения C# к Godot, как я понял - там несоответствие в заголовках функций какое-то, из-за виртуальной машины .NET или чего-то вроде... C# же в байткод компилируется, а не в машинный код. Если движковые модули на одном ЯП, то проблемы нет - преобразование исключается, остаются прыжки.
Я ещё погуглил про Android - да, там можно загружать функции из соседних APK, это позволяет создавать, к примеру, "APK-ключи", различные модули и т.п. У меня несколько таких приложений на телефоне есть... Для игрового движка такое вряд ли имеет смысл, правда, поскольку эти приложения скачиваются отдельно.
Ему не надо выполнять шаги по укладыванию в стек, над контролируемым кодом, компилятор имеет право выдать выполняющий эквивалентные операции.
Пример - он вообще не вызывает функции, хотя они есть, он заинлайнил вычисления. Я ему еще усложнил задачу, заставив брать ввод из командной строки и записывать якобы в многопоточную переменную. Иначе он просто всю программу схлопывает до вывода константы.
>Если это не тред изучения Godot
"Изучение Godot" не равно "изучению подключения рекламных площадок и платёжных операторов к программам на мобильных платформах". Если очень требуется подключить всё это, лучше обращаться к документации Google, Apple, рекламных площадок - основное там будет идентично для любого движка.
Как подключить всё это к Godot? Так, как обычно.
Но если ты вообще в Godot не разбираешься, куда подключать рекламу и донаты? Сделай игру, потом будешь подключать к ней всё, что нужно. Люди это определённо уже делали, т.е. возможность есть.
Если тебе нужно поскорее и без проблем - лучше уж выкупить уже готовое приложение, находящееся в магазинах, у его владельца. Т.е. ты получаешь все необходимые права и будущую прибыль. Издатели приблизительно так и делают - перекупают игры.
P.s. но это касается подконтрольного кода. Там где он не знает - происходит как ты говоришь, укладывание на стек и вызов функции printf, она черный ящик.
>со встройкой рекламы, оплаты етц на обе мобильные платформы
Ты из РФ?
>Туториал
Идешь в ассеты, вбиваешь что нужно
Потом идешь там по кнопочке View Files
Попадаешь в гитхаб, читаешь issues если есть
У меня какой то такой воркфлоу обычно.
>компилятор имеет право выдать выполняющий эквивалентные операции
Это как-то неправильно... Из-за этого могут быть проблемы, как минимум - несовместимости.
>Пример - он вообще не вызывает функции, хотя они есть, он заинлайнил
Ты вызвал компилятор с флагом -O3 - это самые агрессивные оптимизации, которые сильно замедляют компиляцию. Попробуй выбрать флаг -O0 (без оптимизаций) - тогда будет ровно столько call, сколько ты указал в своём коде, машинный код в среднем будет даже компактнее и проще для понимания, а процесс компиляции будет существенно быстрее.
Я поигрался на том сайте с твоего скриншота - инлайн функций не гарантирован даже с -O3 - компилятор сам решает, когда функцию инлайнить, а когда нет, и предсказать это поведение сложно, что тоже плохо для предсказуемого выполнения кода. Например, он может оставить сразу два call подряд внутри цикла while, хотя в исходниках есть только один вызов функции... Судя по всему, может даже выполнить всю функцию заранее и вставить константу-результат вместо императивного кода, что слишком сильно напоминает обман пользователя (оптимизация уровня "rand(): return 4 // число, выбранное броском кубика").
И при этом мы тут можем рассмотреть только то, что происходит в коде уровня "Hello World". Что происходит при компиляции миллионов строк в тысячах файлов? Я вот вижу, как -O3 копипастит огромные блоки кода несколько раз, создавая портянку в несколько раз длиннее минимально необходимой... Может быть, именно поэтому Godot так сильно раздуло, хотя в него практически ничего нового не добавляют? Наоптимизировали на 160+ МБ - теперь загружается почти так же долго, как другие движки...
И потом, мы ведь говорим о МОДУЛЯХ, наподобие Jolt Physics. Когда Jolt был в виде DLL, он весил всего лишь около 3.5 Мб на Windows x64. А сколько он весит в составе Godot? И на сколько отличается по скорости? Сильно сомневаюсь, что есть существенная разница по скорости. Его включили внутрь Godot.exe только чтобы ньюфагам было проще получить более стабильную 3D физику из коробки. Никто не будет делать отдельную DLL для какой-то тривиальной функции типа "return 2 + 2" и потом вызывать каждый раз, когда ему нужно "4". Но из-за ньюфагов, если теперь тебе вообще не нужна 3D физика в одном проекте - иди качай гигабайт исходников и целый день жди компиляции всего с нуля. Если оно вообще скомпилируется с первого раза без ошибок... А потом держи на компе десяток разных билдов редактора и шаблонов, в которых абсолютно одинаковые блоки кода повторяются несколько раз в каждом exe. Бррр, лучше бы я об этом вообще не знал...
> последний пост на борде, больше тут вряд ли буду появляться
Да-да... До встречи послезавтра.
> Нет, ничего общего с таким бредом нет. Рандом работает как раньше
Никто не может гарантировать, что при агрессивных оптимизациях компилятор не взглянет на то как используется рандом, обнаружит, что рандом используется пять раз со статичным сидом, то есть, при каждом запуске прога получает от рандома 5 одинаковых "случайных" чисел, и компилятор просто зашьёт эти числа в экзешник.
Казалось бы нахер он нужен, но я на своей блядской работе не могу даже установить что-нибудь на комп, мне просто не дают права админа
А теперь я могу хоть что-то делать, потихоньку двигаться
А нахрена тебе права админа для годота? Скачал и запустил, он будет работать прямо так. Вскод, дотнет - туда же, их можно поставить без админа. Вот моно без админа не поставить без бубна, это да
Подойди к сисадмину и попроси добавить годо в локальную политику или сделать тебе вторую учётуку на компе где он будет доступен, если нормальные отношения. Если с персональными данными работаете, в принципе он может отказать и это нормально, есть вариант попросить поставить виртуальную машину а там чтобы полные права у тебя были, переключение между ВМ и хостом - за секунду.
>>1037393
Нашел я программу для читает с бумажки молекулярного редактирования и физической симуляции нанодевайсов, а она на Годоте: https://msep.one
Можете в следующую шапку пихнуть.
Кейс nginx'а - это другое (азаза), 8 лет это никого не интересовало, особенно сам Рамблер, а как только сбербанк купил рамблер Сысоеву начали предъявлять.
Так и представил как кабанчик отжимает у анона его пиксельный платформер на флипнутых ассетах. Такая ценность.
>>1037522
Годот еще на мобилках есть. Регулярно вижу на реддите посты от детей, которые ляпают свои игры прямо на телефонах, и код пишут там же.
Наверное уже стал богат и забыл про нас. Но я его не виню.
Да, ты прав, он не требует прав админа же
Мб попробую скачать, но боюсь что палева будет больше
С другой стороны пока в мой монитор редко смотрят прям
Пока слишком мало тут работаю для таких просьб сисьадмину
>>1037536
Это залупа для потеряных душ лет 40ка
Работают одни тети сраки, не думаю что кто-то спиздит мои три куба в редакторе
Мне кажется, на мобиле будет очень неудобно
Лучше уж пересилить себя и дома посидеть над игрой
На завод таких как мы не примут. Собес не пройдём. А некоторые ещё и медкомиссию.
О это я. Я бросил делать про гигахрущ потому что изначально вместо кода написал говно, фикся один баг, создавал новый, всё со всем было взаимосвязано, насрано и неудобно, проще забить. И ещё понял что писать сюжет, диалоги и мир очень сложно простому чувачку. Ещё я по сути там не определился че вообще хотел делать. Кароч проще убить новорожденного.
И ещё деньги на еду закончились и пришлось буквально пиздошить на завод, но ща вот скопил сверху денежек и съебался неделю назад, поэтому полностью занялся новой нсфв игрушкой, где арт, сюжет и диалоги пишет и рисует другой челик.
А так после гигахруща я ещё пытался на говняндекс играх заработать сделав платформер про самурая, но в него никто не поиграл и площадка сама удалила игру. Заработал с рекламы гдет косарь, но в саму рекламу вбухал 10 косарей. Ну как всегда кароч, поэтому на завод ушел. Может в ближайшее время снова придется пойти, потому что мама ругается заебала
func _unhandled_input(_event):
if Input.is_action_pressed(&"toggle_inventory"):
inventory.visible = not inventory.visible
Оно срабатывает много раз, я понимаю что там срутся ивенты от мышки, но есть же какой то правильный путь?
Попробовал _input и is_action_just_pressed - то же самое
проверять что event = InputEventKey - не помогает, при нажатии пары кнопок на клавиатуре такой же эффект
Всё, разобрался случайно, работает event.is_action_pressed
Рад что ты еще с нами. Пости иногда свои поделки.
>И ещё понял что писать сюжет, диалоги и мир очень сложно простому чувачку.
Традиционно посоветую сделать небольшую, четко нацеленную игру. Скоп крип это болезнь, способная убить лучших из нас.
>Пости иногда свои поделки
А я не прекращал, да и прост ща занимаюсь одной конкретной, а там показывать по сути пока нечего, да и показывать каждый пук тоже неправильно. А так вот две другие игры которые делал после дропа гигахруща:
Пиксельную как раз на яндекс выложил, считаю она заебись, нужно только дальше развить и шлефовать, как-то зациклить геймплей и тп. И как-то пропиарить естесно. Но мне лень.
А 3д это будущая игра мечты, ммо экшн с боевой системой из академии джедаев, но я пока тупой и застрял в одном месте, да и занят другим.
>ммо экшн с боевой системой из академии джедаев
Ты случаем не из киберкотлет по жашке? А то у нас так то очень тесное комьюнити и почти все айтишники как раз. Просто еще хз кому могла вспомниться именно боевая система оттуда.
Да я бля джвадцать лет ждал продолжения, заебался сам сделаю
Вертекс есть или был в качестве клона в плане боевки, но там сразу дисней прискакал с авторскимим, так что им пришлось убирать намеки на зв. Хотя он вроде даже бесплатный. Можно было раньше потрогать точно раньше, щас хз, ну в любом мслучае он чето как-то не прижился. Я к чему это - за продолжение дисней выебет.
Конечно, хочется встретиться ещё раз с полюбившимися героями, но это путь в никуда.
Делайте свои сеттинги.
Зато сам наешься пока делаешь.
А свои сеттинги это сложно. Ворлдбилдинг там, персонажи запоминающиеся, лор и все дела.
Ну, наверное другим и вправду сложно. Я-то с детства ворлдбилдинг практикую. Наверное уже и не вижу, насколько это сложно со стороны.
В доцифровую эпоху и рисовал бывало, да. Нынче Азгаар'генератор мои потребности полностью закрывает. Остаётся только названия городов фиксить и дороги подрисовывать. А потом закрываешь глаза и... поехал. На телеге, запряжённой единорогами.
