Добро пожаловать в тред любви, взаимопомощи, иерархических древовидных компонентных систем!
Шапка: https://hipolink.me/godothread
Предыдущий: >>1026834 (OP)
Архивный: >>1022039 (OP)
Шапка: https://hipolink.me/godothread
Предыдущий: >>1026834 (OP)
Архивный: >>1022039 (OP)
>>30865
Вот тебе идея: сделай законченную игру.
Вот тебе идея: сделай законченную игру.
17 Кб, 644x758>>30883
Хотелось что-то более интересное, из простых игр я делал шарики на рейлибе с поиском пути
Хотелось что-то более интересное, из простых игр я делал шарики на рейлибе с поиском пути
>>30896
Я симулятор своей жизни делаю. Воссоздал квартиру, город, соседей, все такое. Симулятор медленного гниения в нищете в хрущевке, тлен и безысходность, путь к единственной концовке.
Я симулятор своей жизни делаю. Воссоздал квартиру, город, соседей, все такое. Симулятор медленного гниения в нищете в хрущевке, тлен и безысходность, путь к единственной концовке.
459 Кб, mp4,1280x720, 0:04
>>30899
Главное, если зайдёшь в игре в свою квартиру, и увидишь как ты сам сидишь играешь в свою игру, то ни в коем случае не подходи к себе в игре.
Главное, если зайдёшь в игре в свою квартиру, и увидишь как ты сам сидишь играешь в свою игру, то ни в коем случае не подходи к себе в игре.
>>30922
Платформа:
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))
Платформа:
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))
>>30922
Платформа:
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))
Платформа:
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))
>>30924
Спасибо. А то тред захватили архитекторы душные. Не осталось места простым одноклеточным уебкам.
Спасибо. А то тред захватили архитекторы душные. Не осталось места простым одноклеточным уебкам.
>>30928
Ну можем обсудить, я особо не думал, что первое пришло в голову то и сделал. Проблема была только с collision.get_position() + moving_vector, если не добавлять эту писечку то тайлмап ебаный округляет до ячейки в которой шарик
Ну можем обсудить, я особо не думал, что первое пришло в голову то и сделал. Проблема была только с collision.get_position() + moving_vector, если не добавлять эту писечку то тайлмап ебаный округляет до ячейки в которой шарик
>>30930
Каждый блок при коллизии с чем угодно (в данном случае) просто делает роскомнадзор. Мячик же в свою очередь умеет только отскакивать.
Каждый блок при коллизии с чем угодно (в данном случае) просто делает роскомнадзор. Мячик же в свою очередь умеет только отскакивать.
>>30931
Можно было и так, но пришлось бы блок делать отдельной сценой и, либо руками расставлять ровно все блоки, либо подгонять чтобы в TileMapLayer она была ровной, а там какое-то несоответствие было, я один раз делал такое и приходилось подбирать позицию картинци в сцене
Можно было и так, но пришлось бы блок делать отдельной сценой и, либо руками расставлять ровно все блоки, либо подгонять чтобы в TileMapLayer она была ровной, а там какое-то несоответствие было, я один раз делал такое и приходилось подбирать позицию картинци в сцене
>>30925
Во-первых, я бы рекомендовал использовать это:
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, чтоб совпадать с порядком записи внутренних классов.
>>30933
Уровни в арканоидах легко генерировать процедурно.
Во-первых, я бы рекомендовал использовать это:
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, чтоб совпадать с порядком записи внутренних классов.
>>30933
>руками расставлять ровно все блоки
Уровни в арканоидах легко генерировать процедурно.
>>30935
Можно, но я об оптимизация не думал даже
>>30935
Не вижу пока проблемы, если приведёшь пример, возможно соглашусь, даже если там какое-нибудь ебанутое переливание света то его можно наложить на блок отдельно
>>30935
Вот это не знал, спасибо
>>30935
Ну это из разряда микрооптимизаций, там сравнение по имени просто по приколу
>>30935
Этот устой я ломаю, мне так логичнее и удобнее чем дописывать перед extends
>>30935
Это был просто арканоид за ~полтора часа из которых 15 минут я срал, 10 минут разбирался с неверно определяемой ячейкой тайлмапа, 2 минуты рисовал блоки в асепрайт, 10 минут переделывал коллизии(т.к. потолок и стены сначала были как WorldBoundaryShape и только при запуске годо сказал что ему не нравится их пересечение и пришлось менять на прямоугольники), он мне не интересен как игра, просто анон предложил сделать
>Потому что move_and_slide() производит много чего абсолютно лишнего
Можно, но я об оптимизация не думал даже
>>30935
>т.к. продвинутые арканоиды навешивают много разных спецэффектов и способностей на блоки
Не вижу пока проблемы, если приведёшь пример, возможно соглашусь, даже если там какое-нибудь ебанутое переливание света то его можно наложить на блок отдельно
>>30935
>- после "if object is Class" редактор скриптов должен автоматически подставлять нужные поля класса
Вот это не знал, спасибо
>>30935
>если нужно сравнивать строки, лучше объявить константу с типом StringName и сравнивать с ней;
Ну это из разряда микрооптимизаций, там сравнение по имени просто по приколу
>>30935
>class_name должен находиться перед extends
Этот устой я ломаю, мне так логичнее и удобнее чем дописывать перед extends
>>30935
>Уровни в арканоидах легко генерировать процедурно.
Это был просто арканоид за ~полтора часа из которых 15 минут я срал, 10 минут разбирался с неверно определяемой ячейкой тайлмапа, 2 минуты рисовал блоки в асепрайт, 10 минут переделывал коллизии(т.к. потолок и стены сначала были как WorldBoundaryShape и только при запуске годо сказал что ему не нравится их пересечение и пришлось менять на прямоугольники), он мне не интересен как игра, просто анон предложил сделать
>>30921
Кстати в гугл плее это вполне себе удачная ниша. Только там арканоиды доведены до крайности, вида "шарики множатся х500, а до ломаемых блоков ты добираешься через туннель в 1 пиксель".
Кстати в гугл плее это вполне себе удачная ниша. Только там арканоиды доведены до крайности, вида "шарики множатся х500, а до ломаемых блоков ты добираешься через туннель в 1 пиксель".
>>30942
Думаю, любая игра с примитивным геймплеем, которую в любой момент можно открыть, поиграть и закрыть, будет удачной для портабл устройств, в том числе и телефона - 2048, судоку туда же.
Думаю, любая игра с примитивным геймплеем, которую в любой момент можно открыть, поиграть и закрыть, будет удачной для портабл устройств, в том числе и телефона - 2048, судоку туда же.
>>30935
В чётвёрке в тайлмап добавили возможность сцены как тайлы устанавливать, то есть, представь себе, блоки в тайлмапе это отдельные объекты со спрайтом, телом, областями, частицами, и этим блокам можно прописать любую тряску, какую пожелаешь.
> Тайлмап тут чрезмерно ограничивает и при этом избыточен - он предназначен для больших статичных ландшафтов.
В чётвёрке в тайлмап добавили возможность сцены как тайлы устанавливать, то есть, представь себе, блоки в тайлмапе это отдельные объекты со спрайтом, телом, областями, частицами, и этим блокам можно прописать любую тряску, какую пожелаешь.
>>30938
Это не оптимизация, у тебя шарик будет СКОЛЬЗИТЬ. Функция move_and_slide() по умолчанию делает до 4 отскоков, прежде чем вернуть контроль твоему коду.
С тайлмапом это не так удобно, как со сценами. Этот тайлмап выглядит преждевременной оптимизацией.
Чем логичнее? Обычно читается так:
Наоборот получается нелогично:
У нас Йода магистр что ли ты?
Вот главная ошибка. Нужно юзать icon.png с Godot.
>оптимизация
Это не оптимизация, у тебя шарик будет СКОЛЬЗИТЬ. Функция move_and_slide() по умолчанию делает до 4 отскоков, прежде чем вернуть контроль твоему коду.
>можно наложить на блок отдельно
С тайлмапом это не так удобно, как со сценами. Этот тайлмап выглядит преждевременной оптимизацией.
>мне так логичнее и удобнее
Чем логичнее? Обычно читается так:
>класс по имени Игрок расширяет CharacterBody2D
Наоборот получается нелогично:
>расширяет CharacterBody2D класс по имени Игрок
У нас Йода магистр что ли ты?
>2 минуты рисовал блоки в асепрайт
Вот главная ошибка. Нужно юзать icon.png с Godot.
>>30957
Интересно, не знал. Не пользуюсь ими вообще. И как, насколько удобно добавлять сцены в тайлы? GridMap позволяет сгенерировать блоки из сцены, но это очень неудобно, по крайней мере как я это помню (давно уже забросил из-за ограниченности GridMap).
Интересно, не знал. Не пользуюсь ими вообще. И как, насколько удобно добавлять сцены в тайлы? GridMap позволяет сгенерировать блоки из сцены, но это очень неудобно, по крайней мере как я это помню (давно уже забросил из-за ограниченности GridMap).
>>30958
Ой всё
А мне удобно мышкой делать сразу линию блок блоков, паттерны можно сохранять.
Тем, что годо генерирует первую строку extends и она определяет к какой ноде прикреплен скрипт, и если поменять тип ноды я буду менять первую строчку, она основная, а class_name это просто алиас, не нужно мне это навязывать, я видел это в документации в рекомендации к оформлению кода, но у меня это не укладывается в логическую цепочку потому что она не класс->базовый класс, а класс ноды->базовый класс->алиас
>>30958
Да, проебался.
Недавно смотрел джем один, с довольно серьёзным призом, ведуший не знает про годо ничё, а в игре ГГ - иконка ебаная и он такой спрашивает "Мы что играем за голову робота в банке?"
>Это не оптимизация, у тебя шарик будет СКОЛЬЗИТЬ. Функция move_and_slide() по умолчанию делает до 4 отскоков, прежде чем вернуть контроль твоему коду.
Ой всё
>С тайлмапом это не так удобно, как со сценами. Этот тайлмап выглядит преждевременной оптимизацией.
А мне удобно мышкой делать сразу линию блок блоков, паттерны можно сохранять.
>Чем логичнее?
Тем, что годо генерирует первую строку extends и она определяет к какой ноде прикреплен скрипт, и если поменять тип ноды я буду менять первую строчку, она основная, а class_name это просто алиас, не нужно мне это навязывать, я видел это в документации в рекомендации к оформлению кода, но у меня это не укладывается в логическую цепочку потому что она не класс->базовый класс, а класс ноды->базовый класс->алиас
>>30958
>Нужно юзать icon.png с Godot.
Да, проебался.
Недавно смотрел джем один, с довольно серьёзным призом, ведуший не знает про годо ничё, а в игре ГГ - иконка ебаная и он такой спрашивает "Мы что играем за голову робота в банке?"
>>30959
Ну так же удобно как и любые тайлы. Вместо ссылок на текстуры в тайлсете ссылки на сцены. Инстанцирование/высвобождение идёт прозрачно под капотом, ты просто индексы меняешь в коде, а тайлы уже сами за себя отвечают.
Ну так же удобно как и любые тайлы. Вместо ссылок на текстуры в тайлсете ссылки на сцены. Инстанцирование/высвобождение идёт прозрачно под капотом, ты просто индексы меняешь в коде, а тайлы уже сами за себя отвечают.
>>30962
Не обязательно, Godot за этим не следит (лол).
Не обязательно, можно забить в 99% случаев.
Это имя заменяет имя файла, сравни:
Семантически это одно и то же.
Использовать это имя ты, по идее, будешь чаще, чем строчку с классом-предком. Ибо class_name вовсе не обязателен и его лучше не писать, если твой скрипт объявляет что-то локальное и малозначимое. Т.е. не засоряй поле видимости классов лишними именами; нужные имена пиши на самом видном месте.
Приведу пример. Ты делаешь класс:
Теперь ты можешь делать так, например:
И т.д. Если тебе это не нужно - забей на class_name.
>она определяет к какой ноде прикреплен скрипт
Не обязательно, 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.
>>30933
С таким траем нашлась неожиданная тупость - детект коллизии на стороне блока практически мертвый номер, только раздутая поверх коллайдера Area2D (именно больше самого коллайдера) срабатывает. Костыльно короче, хотя думал так будет логичнее и лучше, а получилось как всегда. Похер, первый раз на годоте пишу, попробую проапать этот "арканоид". Вектора отскока не рандомными чтоли сделаю, процедурную генерацию, счет какой-нибудь и тд, хз. Потом видеоуроки от школьника гляну чтоли.
С таким траем нашлась неожиданная тупость - детект коллизии на стороне блока практически мертвый номер, только раздутая поверх коллайдера Area2D (именно больше самого коллайдера) срабатывает. Костыльно короче, хотя думал так будет логичнее и лучше, а получилось как всегда. Похер, первый раз на годоте пишу, попробую проапать этот "арканоид". Вектора отскока не рандомными чтоли сделаю, процедурную генерацию, счет какой-нибудь и тд, хз. Потом видеоуроки от школьника гляну чтоли.
Зачем в арканоиде штатная физическая симуляция? Там хватает простейших формул, вся игра строчек 10 занимает. И будет намного точнее работать попиксельно. Коллайдеры по сетке.
>>30974
Можно прикрепить скрипт Node на любую ноду. Ты обычно меняешь ноду на что-то более специальное, изначально выбрав что-то более обобщённое: брал, например, Node, а потом решил добавить смещение, поменял на Node2D или Node3D, а код не исправил.
Это баг и о нём знают, но его не решаются фиксить, потому что некоторые научились его использовать в качестве хака для двойного наследования, поэтому исправлять будут только после добавления Traits.
>>30975
Можно так, на стороне мячика:
Называется "duck typing": "если крякает, крякаем".
Можно прикрепить скрипт Node на любую ноду. Ты обычно меняешь ноду на что-то более специальное, изначально выбрав что-то более обобщённое: брал, например, Node, а потом решил добавить смещение, поменял на Node2D или Node3D, а код не исправил.
Это баг и о нём знают, но его не решаются фиксить, потому что некоторые научились его использовать в качестве хака для двойного наследования, поэтому исправлять будут только после добавления Traits.
>>30975
>детект коллизии на стороне блока
Можно так, на стороне мячика:
>if "hit" in collider: collider.hit()
>else: # ударились в стену, например
Называется "duck typing": "если крякает, крякаем".
>>30975
Как бы да, но можно и сам блок сделать Area2D
>>30977
Я так захотел. Я могу всё сделать на Area2D двигая мячик через изменение позиции и это будет работать, а могу подключить Box2D, наверняка есть расширение и сделать там, зачем спрашивать такие вопросы?!
>>30979
Да, и только так и можно, скрипт "родителя" можно вешать на "наследника". Я обычно меню чарактер на арею или ригид и такой фокус не получается в 99% случаев, это не баг это просто ООП
Как бы да, но можно и сам блок сделать Area2D
>>30977
Я так захотел. Я могу всё сделать на Area2D двигая мячик через изменение позиции и это будет работать, а могу подключить Box2D, наверняка есть расширение и сделать там, зачем спрашивать такие вопросы?!
>>30979
>Можно прикрепить скрипт Node на любую ноду
Да, и только так и можно, скрипт "родителя" можно вешать на "наследника". Я обычно меню чарактер на арею или ригид и такой фокус не получается в 99% случаев, это не баг это просто ООП
>>30979
Мммм... Трейты в гдскрипте. Ух, заживём.
https://github.com/Earewien/godot-traits
> будут только после добавления Traits.
Мммм... Трейты в гдскрипте. Ух, заживём.
https://github.com/Earewien/godot-traits
>>30986
Какой-то лишний геморрой...
Предложение Хуана будет работать просто:
># We can now damage the crate >GTraits.as_damageable(crate).take_damage(10)
Какой-то лишний геморрой...
Предложение Хуана будет работать просто:
>crate.take_damage(10)
>>30984
А вот не факт, там насколько помню если просто менять позицию то будут глюки, поскольку физ движок будет ее перезаписывать своими рассчетами. И правильно двигать через 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) но у меня есть сомнения что это будет всегда работать в правильном порядке.
>Я могу всё сделать на 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) но у меня есть сомнения что это будет всегда работать в правильном порядке.
>>31005
Ты чет из моды выпал. Свистопердящие проекты так оформлялись еще когда нейронки под стол пешком ходили всратых собак генерили.
Ты чет из моды выпал. Свистопердящие проекты так оформлялись еще когда нейронки под стол пешком ходили всратых собак генерили.
43 Кб, 1025x261>>31002
Факт. В 3д с арией делал и детектилось. Конечно если ты позицию только не изменишь настолько, что объект "пролетит" свозь коллизию, это называется вроде гхостинг
У ригид боди своя отдельная история, ему в принципе нельзя задавать позицию после того как он уже существует, хотя он так же подвержен этому эффекту и для этого ввели параметр с пика
>А вот не факт
Факт. В 3д с арией делал и детектилось. Конечно если ты позицию только не изменишь настолько, что объект "пролетит" свозь коллизию, это называется вроде гхостинг
У ригид боди своя отдельная история, ему в принципе нельзя задавать позицию после того как он уже существует, хотя он так же подвержен этому эффекту и для этого ввели параметр с пика
>>31009
Звучит так что банально повезло. У игрока на компе будет другой фреймрейт и все.
Звучит так что банально повезло. У игрока на компе будет другой фреймрейт и все.
>>30856
Так и отлично же. Не отвлекает, а значит наконец то пришло время делать свой клон игрули в которую постоянно залипал там. Лучше же залипать в своей реализации в годоте.
Так и отлично же. Не отвлекает, а значит наконец то пришло время делать свой клон игрули в которую постоянно залипал там. Лучше же залипать в своей реализации в годоте.
В Годот есть нормальный физический движок или надо юзать сторонний, тогда какой?
>>31014
Я тестовую сцену накидал, Area2D - детектор и Area2D - "пуля", пуля постоянно спавнится с увеличением скорости, начиная с 1000, движение происходит примерно по формуле position.x = position.x + speed * delta и был вариант с move_toward в общем то результат одинаковый для любой формулы и process/physics_process - при достижении скорости в 2700 детект не происходит т.к. начинается гостинг.
Далее вместо пули - CharacterBody2D и движением:
velocity.x = speed
move_and_slide()
Тут даёт 2900 и опять гхостинг.
Это для дефолтных коллизий круга и прямоугольника. В принципе терпимо для многих ситуаций, не о прецижион платформере же речь
Я тестовую сцену накидал, Area2D - детектор и Area2D - "пуля", пуля постоянно спавнится с увеличением скорости, начиная с 1000, движение происходит примерно по формуле position.x = position.x + speed * delta и был вариант с move_toward в общем то результат одинаковый для любой формулы и process/physics_process - при достижении скорости в 2700 детект не происходит т.к. начинается гостинг.
Далее вместо пули - CharacterBody2D и движением:
velocity.x = speed
move_and_slide()
Тут даёт 2900 и опять гхостинг.
Это для дефолтных коллизий круга и прямоугольника. В принципе терпимо для многих ситуаций, не о прецижион платформере же речь
>>31002 >>31009
RigidBody можно менять позицию, но:
- это вызывает какие-то перерасчёты (дорого);
- это сбрасывает симуляцию движения (глупо);
- это может вызвать нежелательный телепорт.
Поэтому рекомендуют не трогать их Transform.
Если вам ригид нужно телепортировать - ОК.
>>31024
Если хочешь быстро и без перескоков - RayCast.
Если лазерной точки недостаточно - ShapeCast.
RigidBody можно менять позицию, но:
- это вызывает какие-то перерасчёты (дорого);
- это сбрасывает симуляцию движения (глупо);
- это может вызвать нежелательный телепорт.
Поэтому рекомендуют не трогать их Transform.
Если вам ригид нужно телепортировать - ОК.
>>31024
Если хочешь быстро и без перескоков - RayCast.
Если лазерной точки недостаточно - ShapeCast.
307 Кб, 1080x1202Чёт перданул. А потом ещё спрашивают, почему современные игры лагают - так вот же нахуй, расчёт физики и коллизий в каждом фрейме в случае когда проще и быстрее чекнуть координаты X Y двумя if'ами.
mOdErN_gAmE_dEvElOpMeNt.png
mOdErN_gAmE_dEvElOpMeNt.png
>>31030
Записать ты можешь, но физическому движку на это всё равно, в момент появления рида в сцене его трансформация копируется в физ. движок и обновляется оттуда с большой скоростью, один вариант если ригид "уснёт", ты можешь обновить позицию, но "разбудив" его позиция опять обновится из физ. движка. Если не будить визуально онг "телепортируется" но ты с этим ничего не сделаешь.
>RigidBody можно менять позицию, но
Записать ты можешь, но физическому движку на это всё равно, в момент появления рида в сцене его трансформация копируется в физ. движок и обновляется оттуда с большой скоростью, один вариант если ригид "уснёт", ты можешь обновить позицию, но "разбудив" его позиция опять обновится из физ. движка. Если не будить визуально онг "телепортируется" но ты с этим ничего не сделаешь.
129 Кб, 794x1024>>31044
Давай, покажи, как ты будешь двумя ифами всё проверять иногда(не в каждом фрейме). Научи нас о великий мыслитель
Давай, покажи, как ты будешь двумя ифами всё проверять иногда(не в каждом фрейме). Научи нас о великий мыслитель
>>31044
Не занимайся преждевременными оптимизациями. Если это речь про один единственный объект управляемый игроком - вообще пофиг, там можно на это хоть миллион тактов процессора отложить. Ведь представь там мог быть не шарик, а целый tps контроллер с целыми деревьями анимаций и скелетами костей и все это успевает работать.
Не занимайся преждевременными оптимизациями. Если это речь про один единственный объект управляемый игроком - вообще пофиг, там можно на это хоть миллион тактов процессора отложить. Ведь представь там мог быть не шарик, а целый tps контроллер с целыми деревьями анимаций и скелетами костей и все это успевает работать.
>>31046
А ты буди его, в чём проблема?
Хорошо, ладно, вот задача:
1. Игрок на VehicleBody заехал в круг телепорта.
2. Телепорт выплюнет игрока за 1 км от входа.
3. Машина остаётся с игроком без изменений.
Предлагаешь queue_free() и новый автомобиль?
А если там много кастомизаций, повреждений?
Так вот из-за кого в новых играх долгие загрузки...
>Если не будить
А ты буди его, в чём проблема?
Хорошо, ладно, вот задача:
1. Игрок на VehicleBody заехал в круг телепорта.
2. Телепорт выплюнет игрока за 1 км от входа.
3. Машина остаётся с игроком без изменений.
Предлагаешь queue_free() и новый автомобиль?
А если там много кастомизаций, повреждений?
Так вот из-за кого в новых играх долгие загрузки...
>>31047
Дебич, тебе расписать два ифа, где Х и Y больше равно / меньше равно нужного значения? Твоё ебало просто в рамку и в музей компьютерных игр с подписью "да, вот дебилы-вайбкодеры вроде него разрушили индустрию".
Дебич, тебе расписать два ифа, где Х и Y больше равно / меньше равно нужного значения? Твоё ебало просто в рамку и в музей компьютерных игр с подписью "да, вот дебилы-вайбкодеры вроде него разрушили индустрию".
>>31049
ТЫ же понимаешь, что по такому принципу написано 90% сегодняшней индюшатины у стиме? Они в основном все не на годоте правда, а на юнити, но это только потому что нормисы все в юнити текут в основном.
ТЫ же понимаешь, что по такому принципу написано 90% сегодняшней индюшатины у стиме? Они в основном все не на годоте правда, а на юнити, но это только потому что нормисы все в юнити текут в основном.
>>31050
Бля ты бы сам пошёл попробовал, прежде чем хуйню нести про в чём проблема
>А ты буди его, в чём проблема?
Бля ты бы сам пошёл попробовал, прежде чем хуйню нести про в чём проблема
>>31052
Какой то жирный троль
Какой то жирный троль
>>31066
Ладно, просто меня в детстве пиздили томиком Страуструпа по голове, не обижайся.
Ладно, просто меня в детстве пиздили томиком Страуструпа по голове, не обижайся.
>>31005
>>30997
>>30995
Ваще трейты (типажи) это разновидность интерфейсов, даже лучшее название чем интерфейс, потому что интерфейс в изначальном смысле это все публичные члены класса/объекта/сущности, называть интерфейсом отдельную сущность было ИМХО ошибкой.
В годоте почти придумали годную замену трейтам/интерфейсам - группы. Достаточно было заложить в гдскрипт механизм валидации вхождения в группу. То есть еще с трёшки есть методы типа call_group() там юзается утиная типизация, если член группы может крякнуть, на нём вызывается кряк, и идёт дальше. Достаточно было в этот механизм добавить строгий режим, чтобы в определение группы можно было вписать метод кряк, и чтобы попытка добавления в группу требовала явно реализовать метод кряк. Ну и всё. Получаем трейты/интрфейсы. Да ещё и с поддержкой в инспекторе.
>>30997
Ну ладно. И так сойдёт.
>>30997
>>30995
Ваще трейты (типажи) это разновидность интерфейсов, даже лучшее название чем интерфейс, потому что интерфейс в изначальном смысле это все публичные члены класса/объекта/сущности, называть интерфейсом отдельную сущность было ИМХО ошибкой.
В годоте почти придумали годную замену трейтам/интерфейсам - группы. Достаточно было заложить в гдскрипт механизм валидации вхождения в группу. То есть еще с трёшки есть методы типа call_group() там юзается утиная типизация, если член группы может крякнуть, на нём вызывается кряк, и идёт дальше. Достаточно было в этот механизм добавить строгий режим, чтобы в определение группы можно было вписать метод кряк, и чтобы попытка добавления в группу требовала явно реализовать метод кряк. Ну и всё. Получаем трейты/интрфейсы. Да ещё и с поддержкой в инспекторе.
>>30997
> Предложение Хуана будет работать просто:
Ну ладно. И так сойдёт.
>>31044
Дружок-пирожок, а ты знаешь сложность твоего сравнения ифами? Она нахуй квадратичная, потому что придется делать ифы всех ко всем. А вот физический движок использует тонну способов оптимизировать это говно, и там сложность логарифмическая, потому что используются пространственные структуры данных для быстрого поиска соседних точек. Более того, в 4 рапира на с++(или раст, не помню уже), а гдс имеет минимальный оверхед на доступ к движковым функциям, что баш на баш даст приемлемую производительность, которая будет гораздо лучше твоих ифов при любом раскладе.
Дружок-пирожок, а ты знаешь сложность твоего сравнения ифами? Она нахуй квадратичная, потому что придется делать ифы всех ко всем. А вот физический движок использует тонну способов оптимизировать это говно, и там сложность логарифмическая, потому что используются пространственные структуры данных для быстрого поиска соседних точек. Более того, в 4 рапира на с++(или раст, не помню уже), а гдс имеет минимальный оверхед на доступ к движковым функциям, что баш на баш даст приемлемую производительность, которая будет гораздо лучше твоих ифов при любом раскладе.
>>31068
Звучит как что-то не очень сложное что ты можешь сделать аддоном как Proof of Concept.
Звучит как что-то не очень сложное что ты можешь сделать аддоном как Proof of Concept.
80 Кб, 1628x1752>>31071
Хмм... Хмм.... Подумоем.
Хмм... Хмм.... Подумоем.
>>31069
Ну а я буду иф-елс-ретурн. Оптимизация, шах и мат, и ретурн.
Ну а я буду иф-елс-ретурн. Оптимизация, шах и мат, и ретурн.
>>31069
Жопу ставишь? А то я raylib стартану и накатаю пару строк, если на кону твоя жопа.
>Более того, в 4 рапира на с++(или раст, не помню уже), а гдс имеет минимальный оверхед на доступ к движковым функциям, что баш на баш даст приемлемую производительность, которая будет гораздо лучше твоих ифов при любом раскладе.
Жопу ставишь? А то я raylib стартану и накатаю пару строк, если на кону твоя жопа.
>>31081
Ты даже на гдскрипт не смог пару строк накатать, куда тебе языки взрослых людей
Ты даже на гдскрипт не смог пару строк накатать, куда тебе языки взрослых людей
>>31081
То что твои гдс ифы будут медленее физдвижка? Ясен хуй ставлю.
То что твои гдс ифы будут медленее физдвижка? Ясен хуй ставлю.
>>31069
Ребят, вы чего? Какие ифы всех со всеми в арканоиде? Повторю: это игра на гриде. Там все высчитывается через mod % от x, y и смотрится в массивчике.
Ребят, вы чего? Какие ифы всех со всеми в арканоиде? Повторю: это игра на гриде. Там все высчитывается через mod % от x, y и смотрится в массивчике.
>>31081
А по поводу raylib - скажем так, годот вполне может физически из-за недостатков собственного движкового апи не потянуть тот уровень, при котором кривая сложности расчетов обойдет твою наивную реализацию на чистой сишке без всего оверхеда апи движка. Лучше сравнивай анрил/unity il2cpp с raylib, ручаться не стану, но чисто математически и изза лучше проработанного апи - может результат будет лучше.
А по поводу raylib - скажем так, годот вполне может физически из-за недостатков собственного движкового апи не потянуть тот уровень, при котором кривая сложности расчетов обойдет твою наивную реализацию на чистой сишке без всего оверхеда апи движка. Лучше сравнивай анрил/unity il2cpp с raylib, ручаться не стану, но чисто математически и изза лучше проработанного апи - может результат будет лучше.
>>31087
Ты так позицию мяча просто конвертируешь в ячейку тайлмапы, буквально blocks.local_to_map(collision.get_position()) из кода, в твоём случае будет только ball.position, каждый кадр будешь проверять? и это будет не верно, нужно проверять пересечение круга и прямоугольника.
Скоро фантазёры начнут предлагать вместо использования камеры сдвигать позиции всех объектов относительно игрока.
Ты так позицию мяча просто конвертируешь в ячейку тайлмапы, буквально blocks.local_to_map(collision.get_position()) из кода, в твоём случае будет только ball.position, каждый кадр будешь проверять? и это будет не верно, нужно проверять пересечение круга и прямоугольника.
Скоро фантазёры начнут предлагать вместо использования камеры сдвигать позиции всех объектов относительно игрока.
>>31089
В целом кстати, я подумал, если кешировать точку прошлой коллизии, а затем при новой проверке в случае ненахождения внутри заданной точки применять метрику чебышева + вектор направления в матрице квадартов, при условии что обьекты не будут телепортироваться, тогда сложность будет o(n) в самом худшем случае (поиск первой коллизии) а в самом лучшем - нам понадобится проверить всего 3 соседа, в чуть худшем - 5 соседей. Но обычно только 3. По идее такой алгоритм будет намного быстрее поиска в пространственной структуре, но он очень не любит телепортации. Надо будет опробовать, спасибо анончики за идею.
Могу сказать что это реально работает. Размер сетки из квадратов для коллизий можно очень сильно ужать благодаря такой хитрости. Сдвигать их непосредственно может и не надо (хз о чем ты), но вот конвертировать в пространство игрока стоит, операция копеешная. Тогда игрок будет всегда в центре колизионной сетки, а колизионные обьекты - всегда вокруг него, максимально выжимая небольшой обьем сетки в работу.
В целом кстати, я подумал, если кешировать точку прошлой коллизии, а затем при новой проверке в случае ненахождения внутри заданной точки применять метрику чебышева + вектор направления в матрице квадартов, при условии что обьекты не будут телепортироваться, тогда сложность будет o(n) в самом худшем случае (поиск первой коллизии) а в самом лучшем - нам понадобится проверить всего 3 соседа, в чуть худшем - 5 соседей. Но обычно только 3. По идее такой алгоритм будет намного быстрее поиска в пространственной структуре, но он очень не любит телепортации. Надо будет опробовать, спасибо анончики за идею.
>Скоро фантазёры начнут предлагать вместо использования камеры сдвигать позиции всех объектов относительно игрока.
Могу сказать что это реально работает. Размер сетки из квадратов для коллизий можно очень сильно ужать благодаря такой хитрости. Сдвигать их непосредственно может и не надо (хз о чем ты), но вот конвертировать в пространство игрока стоит, операция копеешная. Тогда игрок будет всегда в центре колизионной сетки, а колизионные обьекты - всегда вокруг него, максимально выжимая небольшой обьем сетки в работу.
>>31093
Похоже на правду. ЕМНИП кармаковский рейкастинг в Wolfenstein 3D работал. Там же чисто аналитически можно узнать на пути линии движения в каких точках пересечения со стенками клеток.
З.ы. а для тех кто будет говорить "ну там же круг!!1" - так в квейке БОКС коллайдер заменен точкой, а толщина стен увеличена на нужное значение. С круглым коллайдером все еще проще будет.
> самом лучшем - нам понадобится проверить всего 3 соседа, в чуть худшем - 5 соседей. Но обычно только 3
Похоже на правду. ЕМНИП кармаковский рейкастинг в Wolfenstein 3D работал. Там же чисто аналитически можно узнать на пути линии движения в каких точках пересечения со стенками клеток.
З.ы. а для тех кто будет говорить "ну там же круг!!1" - так в квейке БОКС коллайдер заменен точкой, а толщина стен увеличена на нужное значение. С круглым коллайдером все еще проще будет.
29 Кб, 300x203Один предлогает делать проверку коллизий круга и квадрата самостоятельно вместо годота, который её делает и так. Второй предлогает quadtree. Третий предлогает BSP деревья кармака. Для арканоида. Вы нормальные вообще?
>>31110
Никто не предлагал BSP деревья, не пизди.
Он не делает "и так", он использует физический движок, что оверкилл по сравнению с простой аналитической формулой линий.
Это буквально как нанимать целый железнодорожный состав чтобы перевезти 1 пакетик доширака.
Никто не предлагал BSP деревья, не пизди.
>Один предлогает делать проверку коллизий круга и квадрата самостоятельно вместо годота, который её делает и так
Он не делает "и так", он использует физический движок, что оверкилл по сравнению с простой аналитической формулой линий.
Это буквально как нанимать целый железнодорожный состав чтобы перевезти 1 пакетик доширака.
29 Кб, 300x203>>31111
Понятно, тред позёров фанатазёров, которые не представляют как работает физический движок, лучше на форуме годота сидеть
>что оверкилл
Понятно, тред позёров фанатазёров, которые не представляют как работает физический движок, лучше на форуме годота сидеть
>>31112
Да уж получше тебя знают, залетун.
Да уж получше тебя знают, залетун.
3,9 Мб, 408x208>подрубать целый движок просчета физики чтобы не ограничить движение шарика внутри поля
Боюсь представить конечный размер экзешника и библиотек с оверхедами.
59 Кб, 779x440>>31115
Боюсь представить конечный размер экзешника и библиотек с оверхедами.
>подрубать целый движок годот когда можно использовать рейлиб или сдл
Боюсь представить конечный размер экзешника и библиотек с оверхедами.
>>31111
Для арканоида сам годот оверкил. О том и говори сразу, не хочется годот, хочется свой велик писать. 100% понимания, но тред не об этом.
>что оверкилл
Для арканоида сам годот оверкил. О том и говори сразу, не хочется годот, хочется свой велик писать. 100% понимания, но тред не об этом.
5,5 Мб, mp4,1080x1080, 0:12
Не кормите тупую залетуху. Репорт и идите делать игры.
>>31121
От годота в первую очередь нужен рендер и шейдеры. Потому что вот это заебешься писать. А вот игровая логика физику вовсе не обязана использовать.
От годота в первую очередь нужен рендер и шейдеры. Потому что вот это заебешься писать. А вот игровая логика физику вовсе не обязана использовать.
103 Кб, 1600x1600>>31120
Зарплату родителей этих мажоров представляете?
>Использовать ЭВМ вместо спичечных коробков и скомканной фольги в картонной обувной коробке
Зарплату родителей этих мажоров представляете?
...А я вот не понимаю, зачем нужны какие-то там "фреймворки" для композиции в играх. Объясните?
Допустим, у нас есть такой компонент:
Композиция - когда объект владеет другим объектом, живущим ровно столько, сколько живёт его владелец. Следовательно, на GDScript мы можем сделать так:
Если мы хотим обратиться к нему, мы просто:
Либо, если у нас несколько таких классов:
Это будет работать, ибо мы гарантируем наличие компонента heath всю жизнь конкретного Enemy. В ситуации, когда нода health вдруг пропала, сцена сломается и движок должен выдать ошибку.
Агрегация - когда объект может иметь ссылку на независимый другой объект; объекты могут быть созданы и удалены отдельно друг от друга. В Godot примером является дерево сцены - добавление нод другим нодам равно агрегации по умолчанию. Тогда реализовать доступ к компоненту можно так:
Если нода не имеет ноду "Health" в потомках или она неподходящего класса, то "health" будет равно null и последняя строчка просто не выполнится. Можно реализовать неуязвимость, удалив ноду "Health".
Собственно, вопрос: чем "фреймворки" могут быть эффективнее этих стандартных подходов Godot?
Допустим, у нас есть такой компонент:
>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?
>>31110
Я вообще мимопроходил, у меня смежная задача но просто умник со своими ифами стриггерил. Кстати квады вроде никто не предлагал, предлагали просто дробить пространство на обычную матрицу и по ней шароебиться.
>>31112
Напротив, мы отлично знаем как работает физдвижок. Проблема в том что в годоте в отличии от условного беви вызов физдвижка сам по себе очень нетривиален, и только этими накладными расходами можно умножить на ноль все плюсы от его применения, и может так статься что будет лучше велосипедить.
Я вообще мимопроходил, у меня смежная задача но просто умник со своими ифами стриггерил. Кстати квады вроде никто не предлагал, предлагали просто дробить пространство на обычную матрицу и по ней шароебиться.
>>31112
Напротив, мы отлично знаем как работает физдвижок. Проблема в том что в годоте в отличии от условного беви вызов физдвижка сам по себе очень нетривиален, и только этими накладными расходами можно умножить на ноль все плюсы от его применения, и может так статься что будет лучше велосипедить.
363 Кб, 740x490>>31133
Отвечает Александр Друзь: В Годоте есть всё что нужно чтобы сделать игру, никакие дополнительные фреймворки не нужны. Все недостающие тебе инструменты ты можешь легко скомпоновать из имеющихся инструментов редактора Годот (как ты и показал в своём посте). Так что ты прав, никаких фреймворков не нужно. Продолжай делать игры.
Отвечает Александр Друзь: В Годоте есть всё что нужно чтобы сделать игру, никакие дополнительные фреймворки не нужны. Все недостающие тебе инструменты ты можешь легко скомпоновать из имеющихся инструментов редактора Годот (как ты и показал в своём посте). Так что ты прав, никаких фреймворков не нужно. Продолжай делать игры.
>>31137
Ваше очко уходит в зрительный зал
Ваше очко уходит в зрительный зал
>>31133
Покажешь где в треде упоминаются фреймоврки для композиции? Или ты про трейты? Трейтам нужна поддержка в языке, да.
Покажешь где в треде упоминаются фреймоврки для композиции? Или ты про трейты? Трейтам нужна поддержка в языке, да.
Прикольно что из сохраненной на диске сцены можно указать nodepath до ноды в другой сохраненной на диске сцене, без загрузки этой второй сцены. Через редаченье .tscn файлов, но все же можно. Не знаю зачем, но можно.
>>31177
Это ведь будет работать только если сцены корректно загрузятся?
Потому что твой Блокнот не проверяет корректность путей в tscn?
Я помню, как приходилось править пути в AnimationPlayer через Блокнот, потому что я как-то не так переместил какую-то ноду и все пути поломались, и Godot не мог их восстановить, ссылаясь на какую-то больше не существующую или перемещённую ноду. Пришлось открыть tscn в Блокноте и вручную пофиксить эти пути - всё заработало.
Для такого фикса править tscn вручную приемлемо, в остальных случаях не рекомендую даже заглядывать туда, потому что всё это генерируется редактором и перезаписывается, поэтому ручные правки скорее всего исчезнут при следующем сохранении сцены.
>указать nodepath до ноды в другой сохраненной на диске сцене
Это ведь будет работать только если сцены корректно загрузятся?
>но все же можно. Не знаю зачем, но можно
Потому что твой Блокнот не проверяет корректность путей в tscn?
Я помню, как приходилось править пути в AnimationPlayer через Блокнот, потому что я как-то не так переместил какую-то ноду и все пути поломались, и Godot не мог их восстановить, ссылаясь на какую-то больше не существующую или перемещённую ноду. Пришлось открыть tscn в Блокноте и вручную пофиксить эти пути - всё заработало.
Для такого фикса править tscn вручную приемлемо, в остальных случаях не рекомендую даже заглядывать туда, потому что всё это генерируется редактором и перезаписывается, поэтому ручные правки скорее всего исчезнут при следующем сохранении сцены.
>>31179
Ага. На самом деле я это обнаружил сохранив группу нод по ПКМ -> save branch as scene, и у одной из сохраненных нод был нодпас указан на ноду, не попавшую в сохраненную группу.
Хорошо, мам, я перестану заглядывать годот-тян под юбку. Нет.
>Это ведь будет работать только если сцены корректно загрузятся?
Ага. На самом деле я это обнаружил сохранив группу нод по ПКМ -> save branch as scene, и у одной из сохраненных нод был нодпас указан на ноду, не попавшую в сохраненную группу.
>в остальных случаях не рекомендую даже заглядывать туда
Хорошо, мам, я перестану заглядывать годот-тян под юбку. Нет.
>>30839 (OP)
Аддон, который мы все тайно жаждали, но боялись попросить:
https://store-beta.godotengine.org/asset/joyless/you-can-do-it/
https://godotengine.org/asset-library/asset/3267
Based & gachapilled.
Зачем делать игры, если можно играть в Godot?
Аддон, который мы все тайно жаждали, но боялись попросить:
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?
12 Кб, 275x300>>31182
Три треда назад было.
Три треда назад было.
>>31180
Тогда это баг редактора, потому что такого быть не должно. Сцена из-за этого может ломаться.
Я не помню, сталкивался с этим или нет, но 100% видел сломанные ссылки на "чужие" ноды...
>у одной из сохраненных нод был нодпас указан на ноду, не попавшую в сохраненную группу.
Тогда это баг редактора, потому что такого быть не должно. Сцена из-за этого может ломаться.
Я не помню, сталкивался с этим или нет, но 100% видел сломанные ссылки на "чужие" ноды...
>>31182
Нинужно, у меня такое ирл есть.
Нинужно, у меня такое ирл есть.
Годогосподам сап, остальным соболезную. Не прекращаю традицию - срать в тред. Моя четвёртая игра на счету. Сделал её на геймджем и на этот раз успел. Не стал сразу постить, так как аккаунт перестали индексировать, но на днях моча всё починила и люди начали играть. В отличие от прошлых проектов, тут появилось подобие геймплея. Но большую часть времени ушло на графику и анимацию, которую один хуй плохо видно. В следующий раз нужно распределить время 50/50.
Алсо 4пик моделька червяка из конца игры, лепил его, лепил, а в получился хуй, лол, но в игре это сложно заметить.
https://rouw-x.itch.io/deserted
Алсо 4пик моделька червяка из конца игры, лепил его, лепил, а в получился хуй, лол, но в игре это сложно заметить.
https://rouw-x.itch.io/deserted
193 Кб, 736x1041сап годач! есть примеры использования типизированного гдскрипта и доквы что он работает на 30-50% быстрее?
>>31249
https://github.com/cariad/gdscript-typed-performance
Это называется бенчмарк.
Не забывай, что в нем обычно происходит только одно какое то вычисление массово.
Игра состоит не только из одного этого момента, поэтому может быть суммарный прирост будет всего процентов 5.
https://github.com/cariad/gdscript-typed-performance
Это называется бенчмарк.
Не забывай, что в нем обычно происходит только одно какое то вычисление массово.
Игра состоит не только из одного этого момента, поэтому может быть суммарный прирост будет всего процентов 5.
>>31249
Бенчмарк тебе уже скинули, хотя мог бы и сам его реализовать всего за пару-тройку минут, например:
Этого должно быть достаточно.
Если хочешь теоретическое обоснование ускорения: нетипизированные переменные - это данные плюс ID, обозначающий тип данных. Зачем нужен ID? Чтобы компьютер знал, что с этими данными делать. Если требуется операция с данными, компьютер сначала проверяет ID, и только потом производит операцию, соответствующую обозначенному типу данных. Т.е. типизация скрывается от программиста, но от неё невозможно избавиться полностью. Компьютер (компилятор или интерпретатор) берёт на себя ответственность за проверку типов вместо тебя.
Когда ты явно обьявляешь типы, ты хранишь только конкретные данные, которые передаются заранее обозначенным операциям. Компьютеру больше нет необходимости проверять тип, потому что ты задал конкретную операцию с данными явным образом. Соответственно, выполнение кода ускоряется - т.к. избавляемся от лишних скрытых от глаз проверок.
Наглядный пример:
Оператор "+" может принимать int, float, string, Vector2, Vector2, и, возможно, другие типы. Что должно будет произойти после вызова sum? Несколько примеров:
Чтобы это всё работало, компьютер должен скрытно произвести операцию сравнения, подобную такой:
И т.д. Очевидно, эти операции тратят какое-то время.
Если мы пишем наш код так:
То компьютеру больше не нужно угадывать значение операции "+", он просто выполняет целочисленное сложение в любом случае. Естественно, это быстрее.
Конкретную реализацию в GDScript я не видел, и всё объяснение чисто на моей интуиции и опыте разных языков программирования. Могу ошибаться.
Ещё интереснее с типизацией Array: чтобы Array мог принимать любые данные, вместо самих данных там сохраняется ссылка на адрес в памяти. Т.е. сначала необходимо перейти по ссылке, проверить тип, и уже потом выполнить запрошенную операцию. Поэтому "обычные" массивы (Array) в GDScript почти такие же медленные, как и Dictionary (ассоциативный массив). Зачастую выгоднее использовать Dictionary вместо динамического массива с произвольными данными.
>доквы что он работает на 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 вместо динамического массива с произвольными данными.
>>31249
Бенчмарк тебе уже скинули, хотя мог бы и сам его реализовать всего за пару-тройку минут, например:
Этого должно быть достаточно.
Если хочешь теоретическое обоснование ускорения: нетипизированные переменные - это данные плюс ID, обозначающий тип данных. Зачем нужен ID? Чтобы компьютер знал, что с этими данными делать. Если требуется операция с данными, компьютер сначала проверяет ID, и только потом производит операцию, соответствующую обозначенному типу данных. Т.е. типизация скрывается от программиста, но от неё невозможно избавиться полностью. Компьютер (компилятор или интерпретатор) берёт на себя ответственность за проверку типов вместо тебя.
Когда ты явно обьявляешь типы, ты хранишь только конкретные данные, которые передаются заранее обозначенным операциям. Компьютеру больше нет необходимости проверять тип, потому что ты задал конкретную операцию с данными явным образом. Соответственно, выполнение кода ускоряется - т.к. избавляемся от лишних скрытых от глаз проверок.
Наглядный пример:
Оператор "+" может принимать int, float, string, Vector2, Vector2, и, возможно, другие типы. Что должно будет произойти после вызова sum? Несколько примеров:
Чтобы это всё работало, компьютер должен скрытно произвести операцию сравнения, подобную такой:
И т.д. Очевидно, эти операции тратят какое-то время.
Если мы пишем наш код так:
То компьютеру больше не нужно угадывать значение операции "+", он просто выполняет целочисленное сложение в любом случае. Естественно, это быстрее.
Конкретную реализацию в GDScript я не видел, и всё объяснение чисто на моей интуиции и опыте разных языков программирования. Могу ошибаться.
Ещё интереснее с типизацией Array: чтобы Array мог принимать любые данные, вместо самих данных там сохраняется ссылка на адрес в памяти. Т.е. сначала необходимо перейти по ссылке, проверить тип, и уже потом выполнить запрошенную операцию. Поэтому "обычные" массивы (Array) в GDScript почти такие же медленные, как и Dictionary (ассоциативный массив). Зачастую выгоднее использовать Dictionary вместо динамического массива с произвольными данными.
>доквы что он работает на 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 вместо динамического массива с произвольными данными.
>>31304
Зачем в геймдев вкатился?
Начинай делать свою игру мечты.
Или что-то, что может принести деньги.
Или ищи вакансии джуна на Godot (удачи).
>что потом?
Зачем в геймдев вкатился?
Начинай делать свою игру мечты.
Или что-то, что может принести деньги.
Или ищи вакансии джуна на Godot (удачи).
>>31322
А никто и не шутил.
Нужно пропускать через себя и думать что именно делаешь, и почему так. А не просто переписывать.
А никто и не шутил.
Нужно пропускать через себя и думать что именно делаешь, и почему так. А не просто переписывать.
247 Кб, 1080x810Посоны (ничего, что я вас так называю?), если серьёзно.
Годот вообще может деньги принести?
Или только на Юнити возможно, где индустрия огромная итд?
Смогу ли я хотя б 80 тысяч в месяц поднимать в Годоте стабильно и не сдохнуть с голоду или опять дворником работать идти и продолжать бухать и курить?
Годот вообще может деньги принести?
Или только на Юнити возможно, где индустрия огромная итд?
Смогу ли я хотя б 80 тысяч в месяц поднимать в Годоте стабильно и не сдохнуть с голоду или опять дворником работать идти и продолжать бухать и курить?
>>31329
Игры могут принести деньги. Не движок. Движок уже приносит деньги Хуану и сотоварищам. Так что делаешь игры и пытаешься их продавать. Если ты умеешь делать интересные игры, ты обязательно заработаешь. Но вообще да, проще вернуться в дворники, так стабильней.
Игры могут принести деньги. Не движок. Движок уже приносит деньги Хуану и сотоварищам. Так что делаешь игры и пытаешься их продавать. Если ты умеешь делать интересные игры, ты обязательно заработаешь. Но вообще да, проще вернуться в дворники, так стабильней.
>>31337
Где бесплатные курсы посмотреть, как сделать платные курсы по производству игр на Годоте?
Где бесплатные курсы посмотреть, как сделать платные курсы по производству игр на Годоте?
>>31338
А гта спб тебе не показать?
А гта спб тебе не показать?
>>31329
Оплачиваемого геймдева не существует, это наеб для гоев. Либо влетаешь по знакомству, либо пилишь киллергейм 10 из 10 сам, пиаришь сам и продаешь сам, да еще успешно, либо всю жизнь работаешь и мечтаешь в стол. А скорее всего только мечатешь и нихуя не делаешь всю жизнь, как и все.
Оплачиваемого геймдева не существует, это наеб для гоев. Либо влетаешь по знакомству, либо пилишь киллергейм 10 из 10 сам, пиаришь сам и продаешь сам, да еще успешно, либо всю жизнь работаешь и мечтаешь в стол. А скорее всего только мечатешь и нихуя не делаешь всю жизнь, как и все.
>>31344
Бля, так и знал что проебался.
Бля, так и знал что проебался.
183 Кб, 565x640>>31350
Для жмотов есть бюджетная версия.
А на сэкономленное тянку купим!
Бюджетную... Но зато лёгкую!
>25 долларов - это слишком много
Для жмотов есть бюджетная версия.
А на сэкономленное тянку купим!
Бюджетную... Но зато лёгкую!
>>31355
Тут всё как с нашим любимым попенсурсом - если хочешь без вирусов и прочих проблем, то конпелируй всё сам себе из исходников. Жидкий силикон продаётся в обычных магазинах для рукоделия - никто не будет спрашивать, что ты там собираешься из него отливать. Главное покупать "platinum cured" силикон - он будет дороже, но безопаснее для здоровья при контакте с телом. Обычный член отлить просто - многие этим занимаются, на Reddit можешь посмотреть подробные инструкции мастеров членоделия, есть даже пошаговые туториалы на Youtube без цензуры.
Хочешь себе синий член в форме Godot, угадал?
А я бы себе лучше Годетту сделал...
Тут всё как с нашим любимым попенсурсом - если хочешь без вирусов и прочих проблем, то конпелируй всё сам себе из исходников. Жидкий силикон продаётся в обычных магазинах для рукоделия - никто не будет спрашивать, что ты там собираешься из него отливать. Главное покупать "platinum cured" силикон - он будет дороже, но безопаснее для здоровья при контакте с телом. Обычный член отлить просто - многие этим занимаются, на Reddit можешь посмотреть подробные инструкции мастеров членоделия, есть даже пошаговые туториалы на Youtube без цензуры.
Хочешь себе синий член в форме Godot, угадал?
А я бы себе лучше Годетту сделал...
>>31371
Я так понимаю, Годетта будет с членом...
Я так понимаю, Годетта будет с членом...
>>31329
Чел, глянь на результаты опросника по годоту, где разрабов спрашивали, какие игры они делают на годоте. Там абсолютное большинство "делают" 3д фпс шутеры. Да, на годоте. Можешь сам глянуть сколько успешных 3д шутеров было выпущено на этом игровом движке. Судя по всему доступные технологии привлекают всяких дегенератов, поэтому их столько и набежало. А те, кто зарабатывает деньги, в основном на юнити пилят 2д индюшатину, тут ты прав. Исключения конечно есть то тут, то там, вроде вон из успешных у детей на годоте это webfishing или как-то так.
>Годот вообще может деньги принести?
Чел, глянь на результаты опросника по годоту, где разрабов спрашивали, какие игры они делают на годоте. Там абсолютное большинство "делают" 3д фпс шутеры. Да, на годоте. Можешь сам глянуть сколько успешных 3д шутеров было выпущено на этом игровом движке. Судя по всему доступные технологии привлекают всяких дегенератов, поэтому их столько и набежало. А те, кто зарабатывает деньги, в основном на юнити пилят 2д индюшатину, тут ты прав. Исключения конечно есть то тут, то там, вроде вон из успешных у детей на годоте это webfishing или как-то так.
>>31427
Завидуй потише.
Завидуй потише.
>>31427
Никакого противоречия. 3д шутеры делают сейчас, значит сделают их позже. 3д шутер делать дольше чем 2д игру. 4-ка не так давно стала популярной.
Никакого противоречия. 3д шутеры делают сейчас, значит сделают их позже. 3д шутер делать дольше чем 2д игру. 4-ка не так давно стала популярной.
>>31427
Кто тебе это сказал? Ты опрос смотрел?
Опрос был о "текущих проектах" (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 квесты).
>большинство "делают" 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 квесты).
>>31427
Кто тебе это сказал? Ты опрос смотрел?
Опрос был о "текущих проектах" (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 квесты).
>большинство "делают" 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 квесты).
>>30839 (OP)
Кто-нибудь тут разбирается в левелдизайне?
Всё понимаю, всё умею... на базовом уровне... Но вот фантазии совсем не хватает ни на что. Как я вообще должен придумывать что-то... эдакое? Везде пишут базовые вещи типа "поставить вышку чтобы игрок заинтересовался", "делать линии, ведущие к цели", "комбинировать передний и задний план" и т.п. Но непонятно, как вообще дойти до чего-то из ничего.
Вот я умею CSG ноды лепить друг на друга. И делал множество пробных "уровней" для своих простых прототипов... Но дальше условных кубов моя мысль отказывается двигаться. Типа, накидал кубы, и что? Конкретной цели у меня нет, сюжета не будет. Мне хотелось просто что-то интересное сделать. Но что? Непонятно, как левелдизайнеры это решают.
Какие-то идеи у меня были, но все они какие-то уж слишком пресные, банальные. Пробовал нейронки - текстовые, графические - они тоже что-то банальное генерируют. Игры чужие смотрел - всё одно и то же. Непонятно... Просто случайный мусор лепить? Но неинтересно же, когда всё налеплено абы как.
А без левелдизана игры не получится.
Кто-нибудь тут разбирается в левелдизайне?
Всё понимаю, всё умею... на базовом уровне... Но вот фантазии совсем не хватает ни на что. Как я вообще должен придумывать что-то... эдакое? Везде пишут базовые вещи типа "поставить вышку чтобы игрок заинтересовался", "делать линии, ведущие к цели", "комбинировать передний и задний план" и т.п. Но непонятно, как вообще дойти до чего-то из ничего.
Вот я умею CSG ноды лепить друг на друга. И делал множество пробных "уровней" для своих простых прототипов... Но дальше условных кубов моя мысль отказывается двигаться. Типа, накидал кубы, и что? Конкретной цели у меня нет, сюжета не будет. Мне хотелось просто что-то интересное сделать. Но что? Непонятно, как левелдизайнеры это решают.
Какие-то идеи у меня были, но все они какие-то уж слишком пресные, банальные. Пробовал нейронки - текстовые, графические - они тоже что-то банальное генерируют. Игры чужие смотрел - всё одно и то же. Непонятно... Просто случайный мусор лепить? Но неинтересно же, когда всё налеплено абы как.
А без левелдизана игры не получится.
>>31547
Есть каналы разбирающие уровни, найди канал левел дизайнера и попробуй посмотреть. Например левелдизайнер из ремеди https://youtube.com/@kirbuyanin
>Но непонятно, как вообще дойти до чего-то из ничего
Есть каналы разбирающие уровни, найди канал левел дизайнера и попробуй посмотреть. Например левелдизайнер из ремеди https://youtube.com/@kirbuyanin
245 Кб, 1901x1077О бля, не увидел что уже перекат был.
Ребят, пилю игру на годоте, первый мой проект, эрпэгэ-рогалик. Прошу рейтануть визуальный стиль, в целом игра так и будет выглядеть. Медленно, но верно двигаюсь к концу разработки, многое уже реализовано, скоро буду к звукам приступать.
Ребят, пилю игру на годоте, первый мой проект, эрпэгэ-рогалик. Прошу рейтануть визуальный стиль, в целом игра так и будет выглядеть. Медленно, но верно двигаюсь к концу разработки, многое уже реализовано, скоро буду к звукам приступать.
>>31427
Да. Умный способен на чём угодно сделать игру, пока дегенераты выясняют, чей движок лучше.
>доступные технологии привлекают всяких дегенератов
Да. Умный способен на чём угодно сделать игру, пока дегенераты выясняют, чей движок лучше.
>>31677
Видел тебя в субшоте. Молодец. Красиво выходит.
Освещение встроенными нодами сделал ведь? Попробуй добавить normal map спрайтам камней:
https://docs.godotengine.org/en/stable/tutorials/2d/2d_lights_and_shadows.html#normal-and-specular-maps
Должно получиться интереснее, особенно пол.
Видел тебя в субшоте. Молодец. Красиво выходит.
Освещение встроенными нодами сделал ведь? Попробуй добавить normal map спрайтам камней:
https://docs.godotengine.org/en/stable/tutorials/2d/2d_lights_and_shadows.html#normal-and-specular-maps
Должно получиться интереснее, особенно пол.
>>31692
Спасибо. Неделю или больше убил на создание освещения, пытался сделать по красоте, чтобы объекты отражали тень, колонны там, сущности всякие. Но столкнулся с тем что физически невозможно сделать так чтобы факел размещённый на стене, мог освещать стену, которая точно также и является окклюдером теней (стены всегда были в тени), и также не смог или не до конца понял как сделать правильный окклюдер анимированным спрайтам, чтобы он учитывал изменение спрайта. По итогу неделю натурально ебался, а по итогу нихуя не вышло, и пришлось делать просто много Light2D с разными текстурами света) Увы, не осилил.
Спасибо. Неделю или больше убил на создание освещения, пытался сделать по красоте, чтобы объекты отражали тень, колонны там, сущности всякие. Но столкнулся с тем что физически невозможно сделать так чтобы факел размещённый на стене, мог освещать стену, которая точно также и является окклюдером теней (стены всегда были в тени), и также не смог или не до конца понял как сделать правильный окклюдер анимированным спрайтам, чтобы он учитывал изменение спрайта. По итогу неделю натурально ебался, а по итогу нихуя не вышло, и пришлось делать просто много Light2D с разными текстурами света) Увы, не осилил.
>>31692
В будущем, когда вся игра будет готова полностью, попробую ещё раз переработать свет полностью, чтобы добавить и тени и прочую муйню, но пока есть вещи поважнее :)
..а ещё что такое "субшот"? Имеешь ввиду скрины в одном из предыдущих тредов? Ибо больше я никуда скрины не публиковал :)
В будущем, когда вся игра будет готова полностью, попробую ещё раз переработать свет полностью, чтобы добавить и тени и прочую муйню, но пока есть вещи поважнее :)
..а ещё что такое "субшот"? Имеешь ввиду скрины в одном из предыдущих тредов? Ибо больше я никуда скрины не публиковал :)
>>31547
Это как в дизайне персонажей, влияет насмотренность. Чем больше вникаешь в чужой удачный левелдизайн, тем лучше получается свой. У меня игра с упором на левелдизайн, и если в начале я тоже лепил кубы, то теперь прям доволен, вертикальность, разнообразие, крутые формы, ух бля. Тем временем мой каталог с рефами, куда я складываю скрины чужих игр с хорошим дизайном, распух до 2гб. Это моя сокровищница нахуй, а я дракон, собираю все больше и больше.
Это как в дизайне персонажей, влияет насмотренность. Чем больше вникаешь в чужой удачный левелдизайн, тем лучше получается свой. У меня игра с упором на левелдизайн, и если в начале я тоже лепил кубы, то теперь прям доволен, вертикальность, разнообразие, крутые формы, ух бля. Тем временем мой каталог с рефами, куда я складываю скрины чужих игр с хорошим дизайном, распух до 2гб. Это моя сокровищница нахуй, а я дракон, собираю все больше и больше.
>>31677
Норм. В целом выглядит как любой другой пиксельный эрпогэ рогалик. Визуально ничем не выделяется ни в плохую сторону, ни в хорошую.
Норм. В целом выглядит как любой другой пиксельный эрпогэ рогалик. Визуально ничем не выделяется ни в плохую сторону, ни в хорошую.
>>31677
Все темное, что происходит вряд ли будет понятно. При этом есть свет с градиентом который выбивается из пиксельного стиля.
Все темное, что происходит вряд ли будет понятно. При этом есть свет с градиентом который выбивается из пиксельного стиля.
>>31719
Пролистал весь тред, не нашёл свои скрины (и слава богу, уже охуел с того что кто-то мои скрины куда-то заливает)
Видимо чел ошибся.
Пролистал весь тред, не нашёл свои скрины (и слава богу, уже охуел с того что кто-то мои скрины куда-то заливает)
Видимо чел ошибся.
>>31732
Значит с уникальностью проблемы. Попробуй чтоль шейдер какой сверху накинуть странный. Узнаваемость важна. Если твоя игра выглядит как 50 других игр того же жанра, то, ну, сам понимаешь.
Значит с уникальностью проблемы. Попробуй чтоль шейдер какой сверху накинуть странный. Узнаваемость важна. Если твоя игра выглядит как 50 других игр того же жанра, то, ну, сам понимаешь.
>>31698
>>31732
Даже на Reddit не заливаешь? Я просто точно помню, как видел какие-то посты с рогаликом, который выглядел почти точь-в-точь как твой скриншот... Особенно GUI очень похож был. Автор поста вроде бы спрашивал, мол, "нормальный GUI для рогалика или нет", или что-то в этом роде. Я ещё много постов с разными играми тогда открыл... но сейчас тот пост найти не могу.
>>31696
Я покопался в 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/
Ну, просто предлагаю вариант, смотри сам, нужно тебе это или нет. Но современные "пиксельные" игры часто используют этот трюк, как мне кажется. Делает картинку живее...
>Ибо больше я никуда скрины не публиковал
>>31732
>кто-то мои скрины куда-то заливает
Даже на Reddit не заливаешь? Я просто точно помню, как видел какие-то посты с рогаликом, который выглядел почти точь-в-точь как твой скриншот... Особенно GUI очень похож был. Автор поста вроде бы спрашивал, мол, "нормальный GUI для рогалика или нет", или что-то в этом роде. Я ещё много постов с разными играми тогда открыл... но сейчас тот пост найти не могу.
>>31696
>невозможно сделать так чтобы факел размещённый на стене, мог освещать стену, которая точно также и является окклюдером теней (стены всегда были в тени)
Я покопался в 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/
Ну, просто предлагаю вариант, смотри сам, нужно тебе это или нет. Но современные "пиксельные" игры часто используют этот трюк, как мне кажется. Делает картинку живее...
>>31698
>>31732
Даже на Reddit не заливаешь? Я просто точно помню, как видел какие-то посты с рогаликом, который выглядел почти точь-в-точь как твой скриншот... Особенно GUI очень похож был. Автор поста вроде бы спрашивал, мол, "нормальный GUI для рогалика или нет", или что-то в этом роде. Я ещё много постов с разными играми тогда открыл... но сейчас тот пост найти не могу.
>>31696
Я покопался в 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/
Ну, просто предлагаю вариант, смотри сам, нужно тебе это или нет. Но современные "пиксельные" игры часто используют этот трюк, как мне кажется. Делает картинку живее...
>Ибо больше я никуда скрины не публиковал
>>31732
>кто-то мои скрины куда-то заливает
Даже на Reddit не заливаешь? Я просто точно помню, как видел какие-то посты с рогаликом, который выглядел почти точь-в-точь как твой скриншот... Особенно GUI очень похож был. Автор поста вроде бы спрашивал, мол, "нормальный GUI для рогалика или нет", или что-то в этом роде. Я ещё много постов с разными играми тогда открыл... но сейчас тот пост найти не могу.
>>31696
>невозможно сделать так чтобы факел размещённый на стене, мог освещать стену, которая точно также и является окклюдером теней (стены всегда были в тени)
Я покопался в 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/
Ну, просто предлагаю вариант, смотри сам, нужно тебе это или нет. Но современные "пиксельные" игры часто используют этот трюк, как мне кажется. Делает картинку живее...
>>31755
Я тебе больше скажу - видел точь в точь такое же уже опубликованным в стиме, пока в распродажах копался.
Я тебе больше скажу - видел точь в точь такое же уже опубликованным в стиме, пока в распродажах копался.
>>31755
Если не сложно, я был бы признателен если бы ты нашёл похожие скрины на Reddit, ибо да, я не публиковал туда ничего.
Насчёт нормал-мапов - я думал об этом, это и реализовать будет не так сложно (до пиксель арта я как раз 3д графикой и текстурированием занимался, понимаю че там к чему) но я хочу сделать прям максимально доступную игру в плане производительности. Если когда нибудь найду способ, было бы круто портировать на какое нибудь древнее говно, типа геймбоя мб или ps1 (вся графика уже нарисована не только в 640х360 но и в 320х180), поэтому пока таких примочек не планирую точно.
Если не сложно, я был бы признателен если бы ты нашёл похожие скрины на Reddit, ибо да, я не публиковал туда ничего.
Насчёт нормал-мапов - я думал об этом, это и реализовать будет не так сложно (до пиксель арта я как раз 3д графикой и текстурированием занимался, понимаю че там к чему) но я хочу сделать прям максимально доступную игру в плане производительности. Если когда нибудь найду способ, было бы круто портировать на какое нибудь древнее говно, типа геймбоя мб или ps1 (вся графика уже нарисована не только в 640х360 но и в 320х180), поэтому пока таких примочек не планирую точно.
>>31757
Да и похуй на самом то деле, главное что я сам для себя знаю что нигде ничего не спиздил, а что там у кого похоже - хуй с ним. Сейчас каждая вторая игра использует интерфейсы с простыми полупрозрачными панельками без какого либо визуального стиля в принципе. А у меня хотя бы так :)
Да и похуй на самом то деле, главное что я сам для себя знаю что нигде ничего не спиздил, а что там у кого похоже - хуй с ним. Сейчас каждая вторая игра использует интерфейсы с простыми полупрозрачными панельками без какого либо визуального стиля в принципе. А у меня хотя бы так :)
>>31759
Вряд ли смогу найти теперь...
Делаешь игру на 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... Не вижу проблемы сделать навороченную версию на ПК и потом сделать "мини"-версию для древней приставки.
Вряд ли смогу найти теперь...
>прям максимально доступную игру в плане производительности
Делаешь игру на 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... Не вижу проблемы сделать навороченную версию на ПК и потом сделать "мини"-версию для древней приставки.
274 Кб, 1901x1077>>31720
Наоборот, слишком светло для данжа и слабый контраст.
Пятно света вокруг героя наверняка перемещается за ним.
А это уже давно норма для современных "пиксельных" игр...
>Все темное, что происходит вряд ли будет понятно.
Наоборот, слишком светло для данжа и слабый контраст.
Пятно света вокруг героя наверняка перемещается за ним.
>свет с градиентом который выбивается из пиксельного стиля
А это уже давно норма для современных "пиксельных" игр...
>>31768
SDL2 софтверный, если туда добавлять свет, тени, нормали, то не факт что это все будет уже шустро. А шейдеры туда добавлять замучаешься. Насчет SDL3 не знаю, но там скорее всего тоже не все просто.
SDL2 софтверный, если туда добавлять свет, тени, нормали, то не факт что это все будет уже шустро. А шейдеры туда добавлять замучаешься. Насчет SDL3 не знаю, но там скорее всего тоже не все просто.
>>31768
Я использую godot 4.3, только потому что мне порекомендовали именно его в начале разработки :) Я знаю про пиксель-данжн, он вроде на джаве написан и/или сделан. Очевидно что там лучше с оптимизацией вообще всё, в отличии от проекта созданного на каком либо движке. Но в любом случае, пока что так. Потом, когда будет больше скилла, можно и переносить на другие движки/платформы, а пока что меня и так устраивает всё.
Я использую godot 4.3, только потому что мне порекомендовали именно его в начале разработки :) Я знаю про пиксель-данжн, он вроде на джаве написан и/или сделан. Очевидно что там лучше с оптимизацией вообще всё, в отличии от проекта созданного на каком либо движке. Но в любом случае, пока что так. Потом, когда будет больше скилла, можно и переносить на другие движки/платформы, а пока что меня и так устраивает всё.
23 Кб, 971x245Йопта помогите. Короче есть дни недели и их нужно менять. Как лучше хранить если менять-то удобнее просто циферку (1, 2, там другой день недели до 7 короче), а при вызове хорошо бы получать именно строку "Понедельник" например. Ещё хорошо бы еслиб оно как-то через экспорт было чтоб я мог через юи выбирать.
На скриншоте неработающая хрень я тупой.
На скриншоте неработающая хрень я тупой.
38 Кб, 980x411>>31783
Короче пока решил хуй забить на вывот дня недели в сам экспорт годота.
Просто сделал, что в зависимости от дня (1, 2, 3) высчитывается день недели который нужно написать.
Короче пока решил хуй забить на вывот дня недели в сам экспорт годота.
Просто сделал, что в зависимости от дня (1, 2, 3) высчитывается день недели который нужно написать.
>>31732
свин гд начинал с этого свою карьеру в 2016, воровал скрины для своего паблика вконтакте
>и слава богу, уже охуел с того что кто-то мои скрины куда-то заливает
свин гд начинал с этого свою карьеру в 2016, воровал скрины для своего паблика вконтакте
>>31802
Внатуре. Спасибо.
Внатуре. Спасибо.
>>31773
Простейший свет тайловой 2D игре можно сделать растягиванием чёрно-белой текстуры очень низкого разрешения, на которой 1 пиксель == 1 тайл, белый - освещённый, чёрный - неосвещённый. Если текстура растягивается с линейным фильтром, получается интересная и дешёвая имитация мягких теней.
Сложнее сделать алгоритм распространения света. Теоретически подходит клеточный автомат, но нужно учитывать источники света за пределами экрана...
>>31778
До сих пор до 4.4 не обновился? Там много всякой оптимизации подвезли. Как правило, переход на следующую минорную версию (x.Y.z) должен быть безболезненным, но лучше сделать бэкап проекта.
Согласен. Я как-то пытался свой движок написать, но ниасилил, перешёл на Godot с мыслью "сейчас игру проработаю, а потом переделаю на свой велосипед". В результате я так и остался тут... Godot комфортнее.
>SDL2 софтверный, если туда добавлять свет, тени
Простейший свет тайловой 2D игре можно сделать растягиванием чёрно-белой текстуры очень низкого разрешения, на которой 1 пиксель == 1 тайл, белый - освещённый, чёрный - неосвещённый. Если текстура растягивается с линейным фильтром, получается интересная и дешёвая имитация мягких теней.
Сложнее сделать алгоритм распространения света. Теоретически подходит клеточный автомат, но нужно учитывать источники света за пределами экрана...
>>31778
>godot 4.3
До сих пор до 4.4 не обновился? Там много всякой оптимизации подвезли. Как правило, переход на следующую минорную версию (x.Y.z) должен быть безболезненным, но лучше сделать бэкап проекта.
>Потом, когда будет больше скилла, можно и переносить на другие движки/платформы, а пока что меня и так устраивает всё.
Согласен. Я как-то пытался свой движок написать, но ниасилил, перешёл на Godot с мыслью "сейчас игру проработаю, а потом переделаю на свой велосипед". В результате я так и остался тут... Godot комфортнее.
>>31783
Можно использовать enum как на скриншоте. В GDScript enum работает как Dictionary:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#enums
>>31802
Так делать не стоит, у 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 очень хорошо сочетается с локализацией.
Можно использовать enum как на скриншоте. В GDScript enum работает как Dictionary:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html#enums
>>31802
Так делать не стоит, у 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 очень хорошо сочетается с локализацией.
>>31839
Не хочу использовать внутреннюю систему локализации годота, хочу жрать говно самостоятельно.
Не хочу использовать внутреннюю систему локализации годота, хочу жрать говно самостоятельно.
>>31839
Нууу... ты так пишешь как будто надо читать документацию и делать игры. Но мы не хотим делать игры, мы хотим делать себе проблемы и потом героически их решать.
Нууу... ты так пишешь как будто надо читать документацию и делать игры. Но мы не хотим делать игры, мы хотим делать себе проблемы и потом героически их решать.
>>30839 (OP)
проверка
проверка
>>31800
самое сложное как не странно это самое неочевидное.
баланс, и генерация. в случае с балансом можно просто через тысячи тестов ещё как то что-то сделать удобоваримое, а вот генерацию пилить это пиздец. я потратил на генерацию предметов, объектов, врагов, генерацию характеристик для этого всегда, а самое главное на генерацию уровней - больше половины времени что я в целом игрой занимаюсь. а я к слову, только спрайты и графику рисовал около трёх месяцев :)
короче для новичка вообще не то, вот прям совсем. меня выручило то что я рисовать умею и музыку писать, и плюс имею по 14-16 часов свободного времени в день на обучение и работу, сложно только с кодом, но убедил себя тем что в голове могу сам "логически накодить" что там и как должно быть, в плане идей то есть проблем не было.
но конечно взялся бы я условно за какой-нибудь простенький часовой хоррор, или новеллку - уже бы сделал скорее всего.
самое сложное как не странно это самое неочевидное.
баланс, и генерация. в случае с балансом можно просто через тысячи тестов ещё как то что-то сделать удобоваримое, а вот генерацию пилить это пиздец. я потратил на генерацию предметов, объектов, врагов, генерацию характеристик для этого всегда, а самое главное на генерацию уровней - больше половины времени что я в целом игрой занимаюсь. а я к слову, только спрайты и графику рисовал около трёх месяцев :)
короче для новичка вообще не то, вот прям совсем. меня выручило то что я рисовать умею и музыку писать, и плюс имею по 14-16 часов свободного времени в день на обучение и работу, сложно только с кодом, но убедил себя тем что в голове могу сам "логически накодить" что там и как должно быть, в плане идей то есть проблем не было.
но конечно взялся бы я условно за какой-нибудь простенький часовой хоррор, или новеллку - уже бы сделал скорее всего.
>>31817
я в блендере около 4-х лет работал, и хорошо запомнил правило что даже на минорные версии нельзя обновляться в рамках одного проекта. каждый проект на своей версии типа. а иначе полный ад и израиль, заебёшься всё выправлять, и не факт что потом переход на предыдущую версию поможет.
изначально я вообще хотел на 3.х.х версии делать, но чёт мне сказали там хуйня и вообще говно, но гайдов на неё конечно поболее будет.
Если и перекачусь, то только после релиза основной игры (может демки) когда надо будет новый контент добавлять.
я в блендере около 4-х лет работал, и хорошо запомнил правило что даже на минорные версии нельзя обновляться в рамках одного проекта. каждый проект на своей версии типа. а иначе полный ад и израиль, заебёшься всё выправлять, и не факт что потом переход на предыдущую версию поможет.
изначально я вообще хотел на 3.х.х версии делать, но чёт мне сказали там хуйня и вообще говно, но гайдов на неё конечно поболее будет.
Если и перекачусь, то только после релиза основной игры (может демки) когда надо будет новый контент добавлять.
14 Кб, 500x350
>>31858
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 научиться пользоваться...
>>31852
Удавалось поиграть в игру на ранних стадиях? Подвох процедурной генерации в том, что обычно она не создаёт интересный геймплей сама по себе... Поэтому её стоит делать в последнюю очередь, когда всё уже более-менее работает без неё. Генерация должна расширять контент в ширину, тогда как игровые механики задают глубину геймплея.
Просто нужно начинать со статичной версии (пара подготовленных карт, пара врагов, пара оружий, пара зелий и т.д.), тогда и новичок справится. А генерацию добавлять постепенно, по мере необходимости (захотелось варианты врагов - сделал генератор врагов и продолжаешь играть; захотелось новых карт - нарезаешь существующие карты и делаешь генератор из уже имеющихся кусочков).
Зато с рогаликом ты многому научился, а чему бы ты научился с новелкой?
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 научиться пользоваться...
>>31852
>потратил на генерацию
Удавалось поиграть в игру на ранних стадиях? Подвох процедурной генерации в том, что обычно она не создаёт интересный геймплей сама по себе... Поэтому её стоит делать в последнюю очередь, когда всё уже более-менее работает без неё. Генерация должна расширять контент в ширину, тогда как игровые механики задают глубину геймплея.
>короче для новичка вообще не то, вот прям совсем
Просто нужно начинать со статичной версии (пара подготовленных карт, пара врагов, пара оружий, пара зелий и т.д.), тогда и новичок справится. А генерацию добавлять постепенно, по мере необходимости (захотелось варианты врагов - сделал генератор врагов и продолжаешь играть; захотелось новых карт - нарезаешь существующие карты и делаешь генератор из уже имеющихся кусочков).
>простенький часовой хоррор, или новеллку
Зато с рогаликом ты многому научился, а чему бы ты научился с новелкой?
298 Кб, 1080x775>>31872
Ты там опять напился на выходных?
>Godot: Уроки Обречённых
>look inside
>Horus x SharOn - Поезда (Lyric video AI)
Ты там опять напился на выходных?
82 Кб, 230x641>>31839
Зачем им второй и третий символ, если они одинаковые? Могли бы оптимизироваться и просто первый писать.
Зачем им второй и третий символ, если они одинаковые? Могли бы оптимизироваться и просто первый писать.
>>31895
А слово "day" (день) в английских днях недели тебя никогда не смущало?
https://en.wiktionary.org/wiki/Monday
https://en.wiktionary.org/wiki/%E6%9C%88%E6%9B%9C%E6%97%A5
https://en.wikipedia.org/wiki/Names_of_the_days_of_the_week#East_Asian_tradition
Короче, это просто слова такие. 月 - буквально "Луна", 日 - "Солнце". Мы же ведь не сокращаем "понедельник" до "пн" в разговорной речи? Хотя могли бы: "увидимся в пн".
А слово "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
Короче, это просто слова такие. 月 - буквально "Луна", 日 - "Солнце". Мы же ведь не сокращаем "понедельник" до "пн" в разговорной речи? Хотя могли бы: "увидимся в пн".
>>31923
У нас *недельник не фигурирует в каждом дне. Ты же не говоришь пятнидельник, средельник, поэтому у нас уже нечего оптимизировать. А у них - есть.
У нас *недельник не фигурирует в каждом дне. Ты же не говоришь пятнидельник, средельник, поэтому у нас уже нечего оптимизировать. А у них - есть.
>>31940
Из-за таких как ты у нас потом ААА индустрия считает 30 фпс силки смуз. А своя игра у меня уже оптимизирована. В голове.
Из-за таких как ты у нас потом ААА индустрия считает 30 фпс силки смуз. А своя игра у меня уже оптимизирована. В голове.
32 Кб, 588x800>>31863
По-моему пиздец как смешно: додик делает пикрилейтед, потом просит помощи в треде, а потом два анона одновременно высмеивают эту ситуацию с велосипедом.
>Опять несмешные шутки пошли...
По-моему пиздец как смешно: додик делает пикрилейтед, потом просит помощи в треде, а потом два анона одновременно высмеивают эту ситуацию с велосипедом.
>>31329
индигеймдев стабильно может приносить бабки только если ты делаешь фури-яой визуальную новеллу на патреоне
все остальные успешные инди разрабы кто не делал фури прон - ошибка выжившего которых можно по пальцам пересчитать
индигеймдев стабильно может приносить бабки только если ты делаешь фури-яой визуальную новеллу на патреоне
все остальные успешные инди разрабы кто не делал фури прон - ошибка выжившего которых можно по пальцам пересчитать
>>31959
Я в соцсетях подписан на пару хуесосов, которые до релиза, даже до демо, умудрились собрать пару тыщ баксов. И нет, это не известные геймдевы, у которых в бекграунде имеются успешные проекты. Это ноунеймы с 2 играми на итче - их опыт как разработчиков хуй да нихуя.
- Чтобы продолжить работу, мне нужно оплатить мои BILLS, накидайте 600 баксов, а в следующем месяце еще 600.
- Открываю продажу ингейм портретов своим бэкерам, 1 портрет 150 баксов.
- Мой ноут ЗДОХ, накидайте 1к на новый, а то никакой игры.
При том что это не фури-яой. У одного лоуполи TPS, у второго пиксельный однобитный сблев. Я хз как это работает. Чисто за счет маркетинга и раскрутки соцсетей?
Кофи так-то меньший процент берет.
Я в соцсетях подписан на пару хуесосов, которые до релиза, даже до демо, умудрились собрать пару тыщ баксов. И нет, это не известные геймдевы, у которых в бекграунде имеются успешные проекты. Это ноунеймы с 2 играми на итче - их опыт как разработчиков хуй да нихуя.
- Чтобы продолжить работу, мне нужно оплатить мои BILLS, накидайте 600 баксов, а в следующем месяце еще 600.
- Открываю продажу ингейм портретов своим бэкерам, 1 портрет 150 баксов.
- Мой ноут ЗДОХ, накидайте 1к на новый, а то никакой игры.
При том что это не фури-яой. У одного лоуполи TPS, у второго пиксельный однобитный сблев. Я хз как это работает. Чисто за счет маркетинга и раскрутки соцсетей?
>патреоне
Кофи так-то меньший процент берет.
>>31996
Во внешнем мире, не в снг? Если да, то почти везде культура оплачивать даже пердеж в подушку с детства прививается, не всегда успешно, особенно если денег нет, но все же там больше людей для которых норма "о, мне нравится что делает этот мужик, подпишусь ему на сотыгу баксов, чтобы потреблять его контент, он ведь так старается" вместо нашего родного "этот пидор потребляет мое время своим сраным девлогом и нихуя не выпускает игру уже пару недель и не хочет бесплатно, еще на деньги жалуется айтишный буржуй, игры делать научился значит панует мразь, буду ссать на него и его игру пока этот гной не выйдет в окно вместе со своим высером". Ну и конечно в любой культуре создатели нсфв контента и шлюхи привилегированы, даже наши дрочеры им на постоянной основе заносят, а потом еще и с распространением бесплатно помогают.
Во внешнем мире, не в снг? Если да, то почти везде культура оплачивать даже пердеж в подушку с детства прививается, не всегда успешно, особенно если денег нет, но все же там больше людей для которых норма "о, мне нравится что делает этот мужик, подпишусь ему на сотыгу баксов, чтобы потреблять его контент, он ведь так старается" вместо нашего родного "этот пидор потребляет мое время своим сраным девлогом и нихуя не выпускает игру уже пару недель и не хочет бесплатно, еще на деньги жалуется айтишный буржуй, игры делать научился значит панует мразь, буду ссать на него и его игру пока этот гной не выйдет в окно вместе со своим высером". Ну и конечно в любой культуре создатели нсфв контента и шлюхи привилегированы, даже наши дрочеры им на постоянной основе заносят, а потом еще и с распространением бесплатно помогают.
>>31996
Слышал что так могут отмывать деньги, типа за ворованые плейстейшоны нал, закидывать себе.
Слышал что так могут отмывать деньги, типа за ворованые плейстейшоны нал, закидывать себе.
>>32037
Для этого НФТ вроде используют. Но в данных случаях у них там публичные донаты/типсы с никами, и куча комментов в соцсетях. Слишком замороченно, а пара тыщ - суммы для запада такие себе.
Для этого НФТ вроде используют. Но в данных случаях у них там публичные донаты/типсы с никами, и куча комментов в соцсетях. Слишком замороченно, а пара тыщ - суммы для запада такие себе.
>>31996
Зато если они обосрутся и не сделают игру за несколько лет, или сделают, но не выполнят всех обещаний, или выполнят всё, но недостаточно круто по мнению донатеров - эти же донатеры их потом заканселят повсюду, задоксят, будут следить и смеяться над каждым их шагом, вызывать на них ментов/SWAT, доводить их друзей и родных до суицида, срать на коврик под дверью, слать пожелания смерти и конверты с самодельными бомбами, и прочие радости жизни. А потом будут публично радоваться, если добьются суицида своей жертвы - добились своего.
Не давайте никаких обещаний и не берите денег без крайней необходимости.
>умудрились собрать пару тыщ баксов
Зато если они обосрутся и не сделают игру за несколько лет, или сделают, но не выполнят всех обещаний, или выполнят всё, но недостаточно круто по мнению донатеров - эти же донатеры их потом заканселят повсюду, задоксят, будут следить и смеяться над каждым их шагом, вызывать на них ментов/SWAT, доводить их друзей и родных до суицида, срать на коврик под дверью, слать пожелания смерти и конверты с самодельными бомбами, и прочие радости жизни. А потом будут публично радоваться, если добьются суицида своей жертвы - добились своего.
Не давайте никаких обещаний и не берите денег без крайней необходимости.
>>32057
Все это можно делать абсолютно бесплатно, повод не нужен.
Все это можно делать абсолютно бесплатно, повод не нужен.
192 Кб, 768x768использовал ли анон вместо встроенного редактора кода - vscode?
замем? что бы использовать какую-то LLM-ку, например copilot или локальный сетап на каком-нибудь continue.dev.
собственно, что интересно мне, так это опыт с разными моделями. как хорошо они работают с godot скриптом? в особенности модели для автокомплита, какой-нибудь qwen2.5 coder, с чатом - хуй с ним, могу и в браузер переключиться
замем? что бы использовать какую-то LLM-ку, например copilot или локальный сетап на каком-нибудь continue.dev.
собственно, что интересно мне, так это опыт с разными моделями. как хорошо они работают с godot скриптом? в особенности модели для автокомплита, какой-нибудь qwen2.5 coder, с чатом - хуй с ним, могу и в браузер переключиться
>>32302
Я использую, без ллмки. С гопотой пизжу просто, когда надо, потому что нищук для агентов. Юзаю, потому что редактор кода в самом годоте заставляет мои старческие глаза болеть. Было бы два моника смог бы стерпеть наверно. Печалит, конечно, что вскодовский плагин на все 100500% функции родного редактора не поддерживает, но что есть достаточно для хуйла вроде меня.
Я использую, без ллмки. С гопотой пизжу просто, когда надо, потому что нищук для агентов. Юзаю, потому что редактор кода в самом годоте заставляет мои старческие глаза болеть. Было бы два моника смог бы стерпеть наверно. Печалит, конечно, что вскодовский плагин на все 100500% функции родного редактора не поддерживает, но что есть достаточно для хуйла вроде меня.
3,2 Мб, 498x298>>32302
Жаль, что в годот никогда не добавят официально, ведь порватки в геймдев-индустрии будут визжать будто резаные, а годот известен своим "friendly" подходом. Было бы просто охуенно иметь ИИ бота для спрайтов прямо в редакторе, и отдельного ИИ бота для работы с кодом - разработка пошла бы в разы быстрее.
Жаль, что в годот никогда не добавят официально, ведь порватки в геймдев-индустрии будут визжать будто резаные, а годот известен своим "friendly" подходом. Было бы просто охуенно иметь ИИ бота для спрайтов прямо в редакторе, и отдельного ИИ бота для работы с кодом - разработка пошла бы в разы быстрее.
>>32314
И правильно сделают что не добавят. Это сторонние инструменты, которые подключаются аддонами-плагинами. Опенсорс это не "добавьте все что я пожелаю", а тот, кто добавляет, берет на себя ответственность заниматься поддержкой. А на поддержку на избавление от ии-галлюцинаций и проверку чистоты получившегося кода надо очень много свободного времени.
И правильно сделают что не добавят. Это сторонние инструменты, которые подключаются аддонами-плагинами. Опенсорс это не "добавьте все что я пожелаю", а тот, кто добавляет, берет на себя ответственность заниматься поддержкой. А на поддержку на избавление от ии-галлюцинаций и проверку чистоты получившегося кода надо очень много свободного времени.
>>32322
Додстер, галлюцинация и чистота кода зависит от самой модели ллм, а не от сайд-панели в интерфейсе годота, годоту вообще не нужно об этом думать. Модель должна свободно выбираться из списка доступных на вкус пользователя, а панель в гуе должна интегрироваться нативно, а не аддонами. Как это сделано в курсоре и виндсурфе, но не только с кодом, а и со спрайтами.
Додстер, галлюцинация и чистота кода зависит от самой модели ллм, а не от сайд-панели в интерфейсе годота, годоту вообще не нужно об этом думать. Модель должна свободно выбираться из списка доступных на вкус пользователя, а панель в гуе должна интегрироваться нативно, а не аддонами. Как это сделано в курсоре и виндсурфе, но не только с кодом, а и со спрайтами.
>>32314
Форкни и добавь, додик залетный ноускильный.
Форкни и добавь, додик залетный ноускильный.
>>32328
Со своим отчимом так разговаривай.
Дохуя от чего зависит, в частвности цифирок (температуры, пенальти за повторы и так далее) которые надо подбирать под каждую модель. И кроме того выбор самих доступных моделей. Значит это какой то менеджер аля ассет стор. И потом мейнтейнеру придется гарантировать доступность всего этого. И гигабайтные скачивания. Короче любому адеквату понятно что этой шизе не место в КОРЕ.
Никто никому ничего не должен.
Годот и так является сценой на самом движке, поэтому у аддонов нет проблем игтегрировать свои панели, так делают все от редакторов террейна до всяких анимаций до цепочек диалогов/квестов.
Единственное что надо сделать в коре - это улучшить поддержку языкового сервера для автодополнений.
Кринж. Не пиши мне больше.
>Додстер
Со своим отчимом так разговаривай.
>галлюцинация и чистота
Дохуя от чего зависит, в частвности цифирок (температуры, пенальти за повторы и так далее) которые надо подбирать под каждую модель. И кроме того выбор самих доступных моделей. Значит это какой то менеджер аля ассет стор. И потом мейнтейнеру придется гарантировать доступность всего этого. И гигабайтные скачивания. Короче любому адеквату понятно что этой шизе не место в КОРЕ.
> а панель в гуе должна интегрироваться нативно, а не аддонами
Никто никому ничего не должен.
Годот и так является сценой на самом движке, поэтому у аддонов нет проблем игтегрировать свои панели, так делают все от редакторов террейна до всяких анимаций до цепочек диалогов/квестов.
Единственное что надо сделать в коре - это улучшить поддержку языкового сервера для автодополнений.
>советовать нейросети для спрайтов
Кринж. Не пиши мне больше.
>>31923
В понедельнике ещё есть буква Д. Поэтому можно говорить "Увидимся в пнд".
> Хотя могли бы: "увидимся в пн".
В понедельнике ещё есть буква Д. Поэтому можно говорить "Увидимся в пнд".
>>32305
Что тебя не устраивает в редакторе Godot?
1. Шрифт можно заменить на любой ttf файл.
2. Размер текста и отступов можно настроить.
3. Настраиваемое субпиксельное сглаживание.
4. Цвет фона и подсветка синтаксиса меняется.
5. Редактор кода можно открыть на весь экран.
6. Редактор кода отделяется в отдельное окно.
>>32302
Попробовал, но мне совсем не понравилось.
>>32314
Официально они даже terrain не добавят никогда.
Ищи плагины - весь редактор гибко настраивается.
Встроенного 2D редактора картинок в Godot нет.
Без ручной доводки JPGи от GenAI малополезны.
>>32328
Зачем? По скорости отличий всё равно не будет...
В крайнем случае можно сделать свою сборочку.
>>32334
Зачем, лол? Это же просто инструмент, а не сервис.
Вот в Godot есть свои собственные шейдеры.
А есть сайт https://godotshaders.com/ от годотера.
Но в Godot нет и не будет качалки шейдеров оттуда.
Скажешь, Godot обязан доставлять тебе шейдеры?
Так же и с LLM. API дали (плагином), дальше - сами.
>заставляет мои старческие глаза болеть
Что тебя не устраивает в редакторе Godot?
1. Шрифт можно заменить на любой ttf файл.
2. Размер текста и отступов можно настроить.
3. Настраиваемое субпиксельное сглаживание.
4. Цвет фона и подсветка синтаксиса меняется.
5. Редактор кода можно открыть на весь экран.
6. Редактор кода отделяется в отдельное окно.
>>32302
>vscode
Попробовал, но мне совсем не понравилось.
>>32314
>в годот никогда не добавят официально
Официально они даже terrain не добавят никогда.
Ищи плагины - весь редактор гибко настраивается.
>иметь ИИ бота для спрайтов прямо в редакторе
Встроенного 2D редактора картинок в Godot нет.
Без ручной доводки JPGи от GenAI малополезны.
>>32328
>должна интегрироваться нативно, а не аддонами
Зачем? По скорости отличий всё равно не будет...
В крайнем случае можно сделать свою сборочку.
>>32334
>мейнтейнеру придется гарантировать доступность
Зачем, лол? Это же просто инструмент, а не сервис.
Вот в Godot есть свои собственные шейдеры.
А есть сайт https://godotshaders.com/ от годотера.
Но в Godot нет и не будет качалки шейдеров оттуда.
Скажешь, Godot обязан доставлять тебе шейдеры?
Так же и с LLM. API дали (плагином), дальше - сами.
>>32305
Что тебя не устраивает в редакторе Godot?
1. Шрифт можно заменить на любой ttf файл.
2. Размер текста и отступов можно настроить.
3. Настраиваемое субпиксельное сглаживание.
4. Цвет фона и подсветка синтаксиса меняется.
5. Редактор кода можно открыть на весь экран.
6. Редактор кода отделяется в отдельное окно.
>>32302
Попробовал, но мне совсем не понравилось.
>>32314
Официально они даже terrain не добавят никогда.
Ищи плагины - весь редактор гибко настраивается.
Встроенного 2D редактора картинок в Godot нет.
Без ручной доводки JPGи от GenAI малополезны.
>>32328
Зачем? По скорости отличий всё равно не будет...
В крайнем случае можно сделать свою сборочку.
>>32334
Зачем, лол? Это же просто инструмент, а не сервис.
Вот в Godot есть свои собственные шейдеры.
А есть сайт https://godotshaders.com/ от годотера.
Но в Godot нет и не будет качалки шейдеров оттуда.
Скажешь, Godot обязан доставлять тебе шейдеры?
Так же и с LLM. API дали (плагином), дальше - сами.
>заставляет мои старческие глаза болеть
Что тебя не устраивает в редакторе Godot?
1. Шрифт можно заменить на любой ttf файл.
2. Размер текста и отступов можно настроить.
3. Настраиваемое субпиксельное сглаживание.
4. Цвет фона и подсветка синтаксиса меняется.
5. Редактор кода можно открыть на весь экран.
6. Редактор кода отделяется в отдельное окно.
>>32302
>vscode
Попробовал, но мне совсем не понравилось.
>>32314
>в годот никогда не добавят официально
Официально они даже terrain не добавят никогда.
Ищи плагины - весь редактор гибко настраивается.
>иметь ИИ бота для спрайтов прямо в редакторе
Встроенного 2D редактора картинок в Godot нет.
Без ручной доводки JPGи от GenAI малополезны.
>>32328
>должна интегрироваться нативно, а не аддонами
Зачем? По скорости отличий всё равно не будет...
В крайнем случае можно сделать свою сборочку.
>>32334
>мейнтейнеру придется гарантировать доступность
Зачем, лол? Это же просто инструмент, а не сервис.
Вот в Godot есть свои собственные шейдеры.
А есть сайт https://godotshaders.com/ от годотера.
Но в Godot нет и не будет качалки шейдеров оттуда.
Скажешь, Godot обязан доставлять тебе шейдеры?
Так же и с LLM. API дали (плагином), дальше - сами.
>>32415
Там есть дерево проекта, а не путающий сблев со скриптами Там можно держать множество открытых проектов разом (например серверный код для игры еще)? Вообще что-то полезное, кроме самого дефолтного редактора, в таком режиме есть? Ну и зачем альтабаться на недоделанную иде, если можно альтабаться на вскод?
>5. Редактор кода можно открыть на весь экран.
>6. Редактор кода отделяется в отдельное окно.
Там есть дерево проекта, а не путающий сблев со скриптами Там можно держать множество открытых проектов разом (например серверный код для игры еще)? Вообще что-то полезное, кроме самого дефолтного редактора, в таком режиме есть? Ну и зачем альтабаться на недоделанную иде, если можно альтабаться на вскод?
>>32314 >>32341
Отставить панику, 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 открыт для всех:
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.
Т.е. даже никаких плагинов не нужно.
>>32416
Проблемы "дерева проекта (скриптов)" в Godot:
1. В Godot основа всего - это Сцена. Ты открываешь несколько вкладок со сценами. Работаешь с нодами открытых сцен. Работаешь с полями нод, ресурсами. Скрипты вторичны и почти всегда зависят от сцен.
2. Многие скрипты не нужно сохранять отдельно от ассоциированной сцены: он хранится внутри tscn. Открывается такой скрипт только вместе со сценой.
3. Скрипты, хранящиеся отдельно от сцен, обычно расположены в папке с родительской сценой и не используются независимо от этой сцены, т.к. сцена сохраняет экспортированные настройки скрипта.
Т.е. "дерево проекта" в Godot - это файловый док с сохранёнными сценами, а не список твоих скриптов. Открывай сцены и ассоцированные с ними скрипты.
Да, можно открыть несколько редакторов Godot.
Godot позволяет хранить всё это в одном проекте и настраивать отдельные шаблоны экспорта - для игры обычный, для сервера headless. В шаблоне экспорта выбираются папки, которые нужно включить в .pck. Подобным образом избегается копирование файлов.
Не зажрался ли ты часом? В Блокноте кодил хоть раз? Рекомендую иногда дауншифтить на Блокнот, чтобы тренироваться. Или вообще писать код на бумаге. Это отрезвляет и обнажает пробелы в твоих навыках. Я стремлюсь отключать лишние костыли в IDE, а то окончательно растеряю программерскую хватку...
Не нужно альт-табаться, редактор скриптов сам будет выходить на передний план при нажатии на ярлычок скрипта в твоей сцене или в файловом доке. Окно это необязательно раскрывать на весь экран, так что тебе остаётся кликнуть на заголовок основного окна, чтоб вернуться. Поэтому можно alt+tab вообще не трогать. Возможно, это работает и с внешними редакторами: в настройках Godot можно указать путь до редактора.
Ты высасываешь претензии из пальца, как будто ты компенсируешь какую-то свою проблему. Чем тебя расстраивает VSCode, что ты тут лаешь на Godot? Довольный пользователь не будет доказывать, что выбранный им продукт лучше всех альтернатив...
>Там есть дерево проекта
Проблемы "дерева проекта (скриптов)" в Godot:
1. В Godot основа всего - это Сцена. Ты открываешь несколько вкладок со сценами. Работаешь с нодами открытых сцен. Работаешь с полями нод, ресурсами. Скрипты вторичны и почти всегда зависят от сцен.
2. Многие скрипты не нужно сохранять отдельно от ассоциированной сцены: он хранится внутри tscn. Открывается такой скрипт только вместе со сценой.
3. Скрипты, хранящиеся отдельно от сцен, обычно расположены в папке с родительской сценой и не используются независимо от этой сцены, т.к. сцена сохраняет экспортированные настройки скрипта.
Т.е. "дерево проекта" в Godot - это файловый док с сохранёнными сценами, а не список твоих скриптов. Открывай сцены и ассоцированные с ними скрипты.
>держать множество открытых проектов разом
Да, можно открыть несколько редакторов Godot.
>например серверный код для игры еще
Godot позволяет хранить всё это в одном проекте и настраивать отдельные шаблоны экспорта - для игры обычный, для сервера headless. В шаблоне экспорта выбираются папки, которые нужно включить в .pck. Подобным образом избегается копирование файлов.
>Вообще что-то полезное, кроме самого редактора
Не зажрался ли ты часом? В Блокноте кодил хоть раз? Рекомендую иногда дауншифтить на Блокнот, чтобы тренироваться. Или вообще писать код на бумаге. Это отрезвляет и обнажает пробелы в твоих навыках. Я стремлюсь отключать лишние костыли в IDE, а то окончательно растеряю программерскую хватку...
>зачем альтабаться
Не нужно альт-табаться, редактор скриптов сам будет выходить на передний план при нажатии на ярлычок скрипта в твоей сцене или в файловом доке. Окно это необязательно раскрывать на весь экран, так что тебе остаётся кликнуть на заголовок основного окна, чтоб вернуться. Поэтому можно alt+tab вообще не трогать. Возможно, это работает и с внешними редакторами: в настройках Godot можно указать путь до редактора.
Ты высасываешь претензии из пальца, как будто ты компенсируешь какую-то свою проблему. Чем тебя расстраивает VSCode, что ты тут лаешь на Godot? Довольный пользователь не будет доказывать, что выбранный им продукт лучше всех альтернатив...
>>32416
Проблемы "дерева проекта (скриптов)" в Godot:
1. В Godot основа всего - это Сцена. Ты открываешь несколько вкладок со сценами. Работаешь с нодами открытых сцен. Работаешь с полями нод, ресурсами. Скрипты вторичны и почти всегда зависят от сцен.
2. Многие скрипты не нужно сохранять отдельно от ассоциированной сцены: он хранится внутри tscn. Открывается такой скрипт только вместе со сценой.
3. Скрипты, хранящиеся отдельно от сцен, обычно расположены в папке с родительской сценой и не используются независимо от этой сцены, т.к. сцена сохраняет экспортированные настройки скрипта.
Т.е. "дерево проекта" в Godot - это файловый док с сохранёнными сценами, а не список твоих скриптов. Открывай сцены и ассоцированные с ними скрипты.
Да, можно открыть несколько редакторов Godot.
Godot позволяет хранить всё это в одном проекте и настраивать отдельные шаблоны экспорта - для игры обычный, для сервера headless. В шаблоне экспорта выбираются папки, которые нужно включить в .pck. Подобным образом избегается копирование файлов.
Не зажрался ли ты часом? В Блокноте кодил хоть раз? Рекомендую иногда дауншифтить на Блокнот, чтобы тренироваться. Или вообще писать код на бумаге. Это отрезвляет и обнажает пробелы в твоих навыках. Я стремлюсь отключать лишние костыли в IDE, а то окончательно растеряю программерскую хватку...
Не нужно альт-табаться, редактор скриптов сам будет выходить на передний план при нажатии на ярлычок скрипта в твоей сцене или в файловом доке. Окно это необязательно раскрывать на весь экран, так что тебе остаётся кликнуть на заголовок основного окна, чтоб вернуться. Поэтому можно alt+tab вообще не трогать. Возможно, это работает и с внешними редакторами: в настройках Godot можно указать путь до редактора.
Ты высасываешь претензии из пальца, как будто ты компенсируешь какую-то свою проблему. Чем тебя расстраивает VSCode, что ты тут лаешь на Godot? Довольный пользователь не будет доказывать, что выбранный им продукт лучше всех альтернатив...
>Там есть дерево проекта
Проблемы "дерева проекта (скриптов)" в Godot:
1. В Godot основа всего - это Сцена. Ты открываешь несколько вкладок со сценами. Работаешь с нодами открытых сцен. Работаешь с полями нод, ресурсами. Скрипты вторичны и почти всегда зависят от сцен.
2. Многие скрипты не нужно сохранять отдельно от ассоциированной сцены: он хранится внутри tscn. Открывается такой скрипт только вместе со сценой.
3. Скрипты, хранящиеся отдельно от сцен, обычно расположены в папке с родительской сценой и не используются независимо от этой сцены, т.к. сцена сохраняет экспортированные настройки скрипта.
Т.е. "дерево проекта" в Godot - это файловый док с сохранёнными сценами, а не список твоих скриптов. Открывай сцены и ассоцированные с ними скрипты.
>держать множество открытых проектов разом
Да, можно открыть несколько редакторов Godot.
>например серверный код для игры еще
Godot позволяет хранить всё это в одном проекте и настраивать отдельные шаблоны экспорта - для игры обычный, для сервера headless. В шаблоне экспорта выбираются папки, которые нужно включить в .pck. Подобным образом избегается копирование файлов.
>Вообще что-то полезное, кроме самого редактора
Не зажрался ли ты часом? В Блокноте кодил хоть раз? Рекомендую иногда дауншифтить на Блокнот, чтобы тренироваться. Или вообще писать код на бумаге. Это отрезвляет и обнажает пробелы в твоих навыках. Я стремлюсь отключать лишние костыли в IDE, а то окончательно растеряю программерскую хватку...
>зачем альтабаться
Не нужно альт-табаться, редактор скриптов сам будет выходить на передний план при нажатии на ярлычок скрипта в твоей сцене или в файловом доке. Окно это необязательно раскрывать на весь экран, так что тебе остаётся кликнуть на заголовок основного окна, чтоб вернуться. Поэтому можно alt+tab вообще не трогать. Возможно, это работает и с внешними редакторами: в настройках Godot можно указать путь до редактора.
Ты высасываешь претензии из пальца, как будто ты компенсируешь какую-то свою проблему. Чем тебя расстраивает VSCode, что ты тут лаешь на Godot? Довольный пользователь не будет доказывать, что выбранный им продукт лучше всех альтернатив...
>>32465
Ты просто не врубаешься в кейс или горишь за годот и все что не он для тебя говно. Тебе не нужно дерево? Окей, твое дело ебаться по своему, а мне нужно Дерево есть в годоте? Есть. Отдельно от скриптов, не будет видно при развертке редактора на весь экран. Если мне их не разворачивать, то окошко для меня крошечное и не удобное. Список скриптов слева в редакторе бесполезная для меня хрень по навигации.
Не на годоте же, что я считал очевидным из сообщения. Пока что я не дошел до уровня, где мне надо несколько редакторов годота для одного проекта иметь.
Вообще вот тебе мой кейс - клиент на годоте, серверный код на го/питоне, вспомогательные скрипты на баше с питоном, интеграционки отдельным проектом, фронт на вью. Хочу и работаю над всем этим сразу в одном инстансе вскода, запрещаешь? уже вижу твой ответ
Очень просто и совсем не говно, да. Главное что сова на годот натянута, остальное не важно.
Ты понял что сказал? Отвечу отдельно на части, а то во всем предложении виднеется диагноз.
1. Не расстраивает и не радует, вынужденная необходимость именно им пользоваться сейчас, был бы другой редактор я бы и к нему годот прикрутил ради удобства.
2. Этот лай с тобой в одной комнате? Был вопрос юзает ли кто другие редакторы, я дал ответ, быстренько вспомнив пару важных мне причин. И даже меня бы они не ебали в другой ситуации. А вот чем тебя так задевает мой выбор, раз важно меня переубедить любой ценой?
Прости, что обидел, ты прав, мои претензии не претензии.
Ты просто не врубаешься в кейс или горишь за годот и все что не он для тебя говно. Тебе не нужно дерево? Окей, твое дело ебаться по своему, а мне нужно Дерево есть в годоте? Есть. Отдельно от скриптов, не будет видно при развертке редактора на весь экран. Если мне их не разворачивать, то окошко для меня крошечное и не удобное. Список скриптов слева в редакторе бесполезная для меня хрень по навигации.
>Да, можно открыть несколько редакторов Godot.
>Godot позволяет хранить всё это в одном проекте и настраивать отдельные шаблоны экспорта - для игры обычный, для сервера headless.
Не на годоте же, что я считал очевидным из сообщения. Пока что я не дошел до уровня, где мне надо несколько редакторов годота для одного проекта иметь.
Вообще вот тебе мой кейс - клиент на годоте, серверный код на го/питоне, вспомогательные скрипты на баше с питоном, интеграционки отдельным проектом, фронт на вью. Хочу и работаю над всем этим сразу в одном инстансе вскода, запрещаешь? уже вижу твой ответ
>Не нужно альт-табаться, редактор скриптов сам будет выходить на передний план при нажатии на ярлычок скрипта в твоей сцене или в файловом доке. Окно это необязательно раскрывать на весь экран, так что тебе остаётся кликнуть на заголовок основного окна, чтоб вернуться.
Очень просто и совсем не говно, да. Главное что сова на годот натянута, остальное не важно.
>Чем тебя расстраивает VSCode, что ты тут лаешь на Godot?
Ты понял что сказал? Отвечу отдельно на части, а то во всем предложении виднеется диагноз.
1. Не расстраивает и не радует, вынужденная необходимость именно им пользоваться сейчас, был бы другой редактор я бы и к нему годот прикрутил ради удобства.
2. Этот лай с тобой в одной комнате? Был вопрос юзает ли кто другие редакторы, я дал ответ, быстренько вспомнив пару важных мне причин. И даже меня бы они не ебали в другой ситуации. А вот чем тебя так задевает мой выбор, раз важно меня переубедить любой ценой?
>Ты высасываешь претензии из пальца
Прости, что обидел, ты прав, мои претензии не претензии.
>>32465
Ты просто не врубаешься в кейс или горишь за годот и все что не он для тебя говно. Тебе не нужно дерево? Окей, твое дело ебаться по своему, а мне нужно Дерево есть в годоте? Есть. Отдельно от скриптов, не будет видно при развертке редактора на весь экран. Если мне их не разворачивать, то окошко для меня крошечное и не удобное. Список скриптов слева в редакторе бесполезная для меня хрень по навигации.
Не на годоте же, что я считал очевидным из сообщения. Пока что я не дошел до уровня, где мне надо несколько редакторов годота для одного проекта иметь.
Вообще вот тебе мой кейс - клиент на годоте, серверный код на го/питоне, вспомогательные скрипты на баше с питоном, интеграционки отдельным проектом, фронт на вью. Хочу и работаю над всем этим сразу в одном инстансе вскода, запрещаешь? уже вижу твой ответ
Очень просто и совсем не говно, да. Главное что сова на годот натянута, остальное не важно.
Ты понял что сказал? Отвечу отдельно на части, а то во всем предложении виднеется диагноз.
1. Не расстраивает и не радует, вынужденная необходимость именно им пользоваться сейчас, был бы другой редактор я бы и к нему годот прикрутил ради удобства.
2. Этот лай с тобой в одной комнате? Был вопрос юзает ли кто другие редакторы, я дал ответ, быстренько вспомнив пару важных мне причин. И даже меня бы они не ебали в другой ситуации. А вот чем тебя так задевает мой выбор, раз важно меня переубедить любой ценой?
Прости, что обидел, ты прав, мои претензии не претензии.
Ты просто не врубаешься в кейс или горишь за годот и все что не он для тебя говно. Тебе не нужно дерево? Окей, твое дело ебаться по своему, а мне нужно Дерево есть в годоте? Есть. Отдельно от скриптов, не будет видно при развертке редактора на весь экран. Если мне их не разворачивать, то окошко для меня крошечное и не удобное. Список скриптов слева в редакторе бесполезная для меня хрень по навигации.
>Да, можно открыть несколько редакторов Godot.
>Godot позволяет хранить всё это в одном проекте и настраивать отдельные шаблоны экспорта - для игры обычный, для сервера headless.
Не на годоте же, что я считал очевидным из сообщения. Пока что я не дошел до уровня, где мне надо несколько редакторов годота для одного проекта иметь.
Вообще вот тебе мой кейс - клиент на годоте, серверный код на го/питоне, вспомогательные скрипты на баше с питоном, интеграционки отдельным проектом, фронт на вью. Хочу и работаю над всем этим сразу в одном инстансе вскода, запрещаешь? уже вижу твой ответ
>Не нужно альт-табаться, редактор скриптов сам будет выходить на передний план при нажатии на ярлычок скрипта в твоей сцене или в файловом доке. Окно это необязательно раскрывать на весь экран, так что тебе остаётся кликнуть на заголовок основного окна, чтоб вернуться.
Очень просто и совсем не говно, да. Главное что сова на годот натянута, остальное не важно.
>Чем тебя расстраивает VSCode, что ты тут лаешь на Godot?
Ты понял что сказал? Отвечу отдельно на части, а то во всем предложении виднеется диагноз.
1. Не расстраивает и не радует, вынужденная необходимость именно им пользоваться сейчас, был бы другой редактор я бы и к нему годот прикрутил ради удобства.
2. Этот лай с тобой в одной комнате? Был вопрос юзает ли кто другие редакторы, я дал ответ, быстренько вспомнив пару важных мне причин. И даже меня бы они не ебали в другой ситуации. А вот чем тебя так задевает мой выбор, раз важно меня переубедить любой ценой?
>Ты высасываешь претензии из пальца
Прости, что обидел, ты прав, мои претензии не претензии.
хочу попробовать сделать небольшую мультиплеерную игру на годо. пошаг. в серверной разработке я не прям шарю. правильно я понимаю, что сервер пишется на условном питоне а клиент - годо игра собственно. я прочитал что лучше 3 версию для этого использовать так как в 4 там сокеты зафаршмачили или что-то еще. кто пробовал вообще? как полет?
>>32798
У тебя 4:3 экран что ли? Мне 16:10 на всё хватает.
Можно тогда скрыть список скриптов в редакторе, перенести каталог файлов на левую часть экрана и растянуть окошко скриптов вправо, всё будет норм.
Так бы сразу и говорил, что велосипедист. Как ты серверную версию Godot запускаешь, чтобы физику обрабатывать? Или у тебя там карточная игра?
Обсуждали, кто пишет в VSCode на GDScript вместо встроенного редактора. Никто не спрашивал про совершенно другие языки в других проектах. Если использовать только GDScript, редактор Godot будет очевидным выбором, не так ли? Ты ж не сказал, что используешь кучу других языков и фреймворков на совершенно не связанных с Godot проектах.
>окошко для меня крошечное и не удобное
У тебя 4:3 экран что ли? Мне 16:10 на всё хватает.
>Дерево есть в годоте? Есть.
>Список скриптов слева в редакторе бесполезен
Можно тогда скрыть список скриптов в редакторе, перенести каталог файлов на левую часть экрана и растянуть окошко скриптов вправо, всё будет норм.
>код на го/питоне
Так бы сразу и говорил, что велосипедист. Как ты серверную версию Godot запускаешь, чтобы физику обрабатывать? Или у тебя там карточная игра?
Обсуждали, кто пишет в VSCode на GDScript вместо встроенного редактора. Никто не спрашивал про совершенно другие языки в других проектах. Если использовать только GDScript, редактор Godot будет очевидным выбором, не так ли? Ты ж не сказал, что используешь кучу других языков и фреймворков на совершенно не связанных с Godot проектах.
>>32838
Нормально всё с сокетами в Godot 4. Сервер можно спокойно писать и на GDScript. Читай туториалы, в документации есть основы. Но если у тебя мало геймдев опыта, лучше сначала сделай синглплеер.
Нормально всё с сокетами в Godot 4. Сервер можно спокойно писать и на GDScript. Читай туториалы, в документации есть основы. Но если у тебя мало геймдев опыта, лучше сначала сделай синглплеер.
>>32838
Да, 3 нормально использовать, 4-ка нужна только если прям ААА графон на ПК 4080 хочешь.
Смотря какая игра. Если скажем шутер, то логичней и сервер делать на годоте (а ля квейк/каэсик), в режиме headless. Когда физика считается пульки летают, просто не рисуется графон. И потом рассылается клиентам.
А твой вариант хорош для каких то пошаговых игр, типа вести прогресс в аккаунте матч-3.
Да, 3 нормально использовать, 4-ка нужна только если прям ААА графон на ПК 4080 хочешь.
Смотря какая игра. Если скажем шутер, то логичней и сервер делать на годоте (а ля квейк/каэсик), в режиме headless. Когда физика считается пульки летают, просто не рисуется графон. И потом рассылается клиентам.
А твой вариант хорош для каких то пошаговых игр, типа вести прогресс в аккаунте матч-3.
>>32849
Смысл твоей шутки от меня ускользнул...
Смысл твоей шутки от меня ускользнул...
>>32843
если конечная цель захостить с возможностями:
- автопоиска соперника для игры
- создание акков
то онли годот подойдет получается?
не выйдет ли код сильно больше или медленнее если писать на гдскрипте вместо чего-нибудь там?
если конечная цель захостить с возможностями:
- автопоиска соперника для игры
- создание акков
то онли годот подойдет получается?
не выйдет ли код сильно больше или медленнее если писать на гдскрипте вместо чего-нибудь там?
>>32858
Не любой, игра может быть и peer to peer - когда клиенты просто между собой общаются.
Тут в чем может быть нюанс. Допустим ты сделаешь клиент на годоте а сервер на питоне. Ну во первых тебе игру почти два раза писать на разных, хоть и похожих языках. Во вторых нет гарантии что ты не напутаешь и похоже выглядящая конструкция будет вести себя по разной логике. Как банальный пример - округление какое нибудь. То есть делать сервер на годоте звучит более логично. Но его может быть сложнее захостить, потому что в вебе все таки все задочено под популярные языки, а тут надо что то вроде vps.
Не любой, игра может быть и peer to peer - когда клиенты просто между собой общаются.
Тут в чем может быть нюанс. Допустим ты сделаешь клиент на годоте а сервер на питоне. Ну во первых тебе игру почти два раза писать на разных, хоть и похожих языках. Во вторых нет гарантии что ты не напутаешь и похоже выглядящая конструкция будет вести себя по разной логике. Как банальный пример - округление какое нибудь. То есть делать сервер на годоте звучит более логично. Но его может быть сложнее захостить, потому что в вебе все таки все задочено под популярные языки, а тут надо что то вроде vps.
>>32859
если ты про сами языки, то опыта в питоне у меня нормально. просто бекендом я не занимался никогда. почему игру почти два раза надо будет писать? логика - сервер, визуал - годо. попробую пока через питон.
если ты про сами языки, то опыта в питоне у меня нормально. просто бекендом я не занимался никогда. почему игру почти два раза надо будет писать? логика - сервер, визуал - годо. попробую пока через питон.
>>32859
Ну пчел, ну ты чего. Если ты делаешь что-то хоть сколько-нибудь уникальное-интересное-полезное, не важно в вебдеве или геймдеве, то тебе все равно свой впс нужен, с консолькой и всем-всем. А "заточки" это круды клепать и чужие докеры запускать. Тем более голый сервер зачастую обходится дешевле чем твои заточки.
> Но его может быть сложнее захостить, потому что в вебе все таки все задочено под популярные языки, а тут надо что то вроде vps.
Ну пчел, ну ты чего. Если ты делаешь что-то хоть сколько-нибудь уникальное-интересное-полезное, не важно в вебдеве или геймдеве, то тебе все равно свой впс нужен, с консолькой и всем-всем. А "заточки" это круды клепать и чужие докеры запускать. Тем более голый сервер зачастую обходится дешевле чем твои заточки.
>>32905
Я пользуюсь разными бесплатными хостингами в которых есть консолька, но только под стек который есть, ну и в целом там сеть часто рассчитана на запрос-ответ, а не постоянную работу приложения.
Я пользуюсь разными бесплатными хостингами в которых есть консолька, но только под стек который есть, ну и в целом там сеть часто рассчитана на запрос-ответ, а не постоянную работу приложения.
>>32867
Потому что в настоящих, качественных онлайн-играх игровые расчёты происходят на сервере и на клиентах независимо, но периодически синхронизируясь. Благодаря такой независимой работе становится возможно прогнозирование событий при низком пинге и точный учёт попаданий по хитбоксам. Ну и как вишенка на торте - надёжная защита от читеров.
> почему игру почти два раза надо будет писать?
Потому что в настоящих, качественных онлайн-играх игровые расчёты происходят на сервере и на клиентах независимо, но периодически синхронизируясь. Благодаря такой независимой работе становится возможно прогнозирование событий при низком пинге и точный учёт попаданий по хитбоксам. Ну и как вишенка на торте - надёжная защита от читеров.
>>32938
Ага помню-помню, клиент симулирует потерю пакетов и летит по небу большими скачками. Защита / 10
>Ну и как вишенка на торте - надёжная защита от читеров.
Ага помню-помню, клиент симулирует потерю пакетов и летит по небу большими скачками. Защита / 10
>>32942
На сервере не предусмотрели, что персонаж не может так летать. При потере пакетов он должен остановиться, потому что в пакетах от клиента прилетает инпут - нет пакетов = нет движения. А раз сервер допускает скачки на километр - это значит КГ/АМ.
И ещё это означает что сервер в синхронизации действует как вторичное звено, а должен быть первичным. Вся главная симуляция кинематики происходит на сервере, клиент делает свою симуляцию и сверяется с сервером, поправляя себя (а не сервер).
На сервере не предусмотрели, что персонаж не может так летать. При потере пакетов он должен остановиться, потому что в пакетах от клиента прилетает инпут - нет пакетов = нет движения. А раз сервер допускает скачки на километр - это значит КГ/АМ.
И ещё это означает что сервер в синхронизации действует как вторичное звено, а должен быть первичным. Вся главная симуляция кинематики происходит на сервере, клиент делает свою симуляцию и сверяется с сервером, поправляя себя (а не сервер).
>>32955
Я вот щас не понял этого пассажа. Ты предполагаешь что игровые серверы онлайн-игр СЛАБЕЕ клиентов? Не, ну в таком случае конечно гудлак, просто я слышал ровно противоположное. Про серверные технологии.
Я вот щас не понял этого пассажа. Ты предполагаешь что игровые серверы онлайн-игр СЛАБЕЕ клиентов? Не, ну в таком случае конечно гудлак, просто я слышал ровно противоположное. Про серверные технологии.
>>32957
Я не он, прост мимо проходил, но у меня большой опыт с серверами, больше чем в геймдеве. Серверное железо не магическое железо из будущего, оно просто заточено на параллельность вычислений. Кластеры из 100500 серверов в 100500 потоков. Если код, запущенный на серверах, не распараллелен нормально, то хуй там а не скорость. Поэтому в вебдеве принято городить кучу воркеров вместо одного процесса.
Дальше уже про геймдев и мои догадки. Долгое время я гонял в одну ммо-дрочильню, и она начинала жестко лагать, когда ~600 людей сбивались в кучу и агрессивно кастовали спеллы, эффекты которых высчитывались на серверах. Лагала в эти моменты она у всех, скиллы кастовались по 30 секунд вместо инстант каста, при этом пинг и фпс в норме, никакого раббербандинга, передвижение толпы персонажей работало ок, и было принято разбежаться по углам и дать серверу продохнуть пару минут. Полагаю у них задыхался нераспаралелленый числодробительный поток, обсчитывающий именно скиллы. Такшто как сделаешь так и будет.
Я не он, прост мимо проходил, но у меня большой опыт с серверами, больше чем в геймдеве. Серверное железо не магическое железо из будущего, оно просто заточено на параллельность вычислений. Кластеры из 100500 серверов в 100500 потоков. Если код, запущенный на серверах, не распараллелен нормально, то хуй там а не скорость. Поэтому в вебдеве принято городить кучу воркеров вместо одного процесса.
Дальше уже про геймдев и мои догадки. Долгое время я гонял в одну ммо-дрочильню, и она начинала жестко лагать, когда ~600 людей сбивались в кучу и агрессивно кастовали спеллы, эффекты которых высчитывались на серверах. Лагала в эти моменты она у всех, скиллы кастовались по 30 секунд вместо инстант каста, при этом пинг и фпс в норме, никакого раббербандинга, передвижение толпы персонажей работало ок, и было принято разбежаться по углам и дать серверу продохнуть пару минут. Полагаю у них задыхался нераспаралелленый числодробительный поток, обсчитывающий именно скиллы. Такшто как сделаешь так и будет.
>>32966
Пофиксил.
> Серверное железо не магическое железо из будущего, оно просто мощнее твоей днищепекарни.
Пофиксил.
>>31881
ты во многом супер прав друг.
насчёт первого тейка - да, я так и делал, основной тестовый уровень, и на нём все механики, предметы, эффекты, тестовые враги и так далее. генерация в последнюю очередь
насчёт того что многому с рогаликом научился? - да, бесспорно, душа поёт прямо насколько себя хорошо чувствую все эти недели и месяцы разработки потому что это мечта с пиздючества, когда в 11 лет пытался игры на ргм делать. а вот карман нихуя не поёт, могу делать по 12 часов день ТОЛЬКО потому что мне недавно только 20 стукнуло, и ещё полгодика гдет я могу себе позволить перебиваться случайными доходами, а потом когда придется сьезжать и платить за аренду и прочее, если к этому времени игра не начнет приносить хотя бы базовый доход - придется в долгий ящик забросить желание пилить игрульки.
ты во многом супер прав друг.
насчёт первого тейка - да, я так и делал, основной тестовый уровень, и на нём все механики, предметы, эффекты, тестовые враги и так далее. генерация в последнюю очередь
насчёт того что многому с рогаликом научился? - да, бесспорно, душа поёт прямо насколько себя хорошо чувствую все эти недели и месяцы разработки потому что это мечта с пиздючества, когда в 11 лет пытался игры на ргм делать. а вот карман нихуя не поёт, могу делать по 12 часов день ТОЛЬКО потому что мне недавно только 20 стукнуло, и ещё полгодика гдет я могу себе позволить перебиваться случайными доходами, а потом когда придется сьезжать и платить за аренду и прочее, если к этому времени игра не начнет приносить хотя бы базовый доход - придется в долгий ящик забросить желание пилить игрульки.
54 Кб, 400x1000>>32972
Шутник, ты опять нашутил в тред не подумав? Анон правильно говорит: сервер == многопоточность и энергоэффективность, а ещё тонны RAM и PCI-E. Производительность одного ядра в 2 раза ниже, в противном случае датацентры просто сгорали бы. Информация свободно доступна онлайн - изучай.
>>32966
В ММО обычно мир делится на локации, которые обрабатываются параллельно - на разных ядрах, процессорах, серверных нодах и т.д. Это даёт игре возможность содержать тысячи игроков в одном бесшовном мире. В одной локации игрокам обычно запрещают толпиться, но если разрешают, то игру, естественно, может начать трясти в этой локации. Остальные локации должны работать как обычно.
>>32955
Во-первых, серверная симуляция физики сотни управляемых игроками персонажей почти не будет отличаться от симуляции 99 NPC и 1 игрока в чисто однопользовательской, полностью локальной игре. Единственное отличие в том, откуда приходит вся необходимая информация и куда идут результаты. Естественно, что в ММО игроки делятся на группы небольшого размера - симуляция идёт по локациям.
Во-вторых, симуляция на сервере часто значительно медленнее частоты кадров на клиенте: 15 Гц будет достаточно для условной ММОРПГ с автоматически наводящимися на цель навыками. По-моему, даже в соревновательных шутерах используют около 30 Гц. Симуляция на клиенте от 60 Гц и выше нужна ради плавности картинки без лишней интерполяции. Да и массово многопользовательские игры геймплейно оптимизируются: те же самонаводящиеся навыки значительно проще предсказать/интерполировать.
В-третьих, в синглплеере ПК нужно обработать массу информации, зависящей от результатов всего цикла физической симуляции: передвинуть модели, задать анимации, скрыть лишнее и показать нужное и т.д. В мультиплеере этим занимается в основном клиент, а передачу данных сервер может делать параллельно симуляции физики, т.е. нет искусственных задержек.
Короче, серверный CPU по ядру может быть слабее клиентского и при этом не сильно нагружен даже в массовом мультиплеере. Серверу нужны только многопоточность и широкий канал связи.
>>32851
>>32858
Ты бы лучше больше подробностей рассказал.
Например, сколько игроков в матче? Будут ли у них рейтинги Elo? Соревнования? Таблицы рекордов? Специальный чат в глобальном/локальном лобби? Матчмейкинг выбирает кого угодно или оценивает удалённость клиентов друг от друга или их навыки? Создаётся ли игроками особый контент на сервере? Собираешься ли всерьёз монетизировать проект?
Возьмём самый примитивный вариант:
- никаких чатов, рейтингов и таблиц рекордов;
- матчмейкер соединяет первых попавшихся;
- в матче может быть всего лишь два игрока;
- туннелирование будет средствами Steam.
С такими вводными сервер пиши хоть на PHP.
Пример диалога с простейшим REST сервером:
Дальше - общение клиентов через TCP или UDP:
В данном случае оба клиента - 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-чат только... Остальное знаю из множества каких-то статей про онлайн геймдев.
Шутник, ты опять нашутил в тред не подумав? Анон правильно говорит: сервер == многопоточность и энергоэффективность, а ещё тонны RAM и PCI-E. Производительность одного ядра в 2 раза ниже, в противном случае датацентры просто сгорали бы. Информация свободно доступна онлайн - изучай.
>>32966
В ММО обычно мир делится на локации, которые обрабатываются параллельно - на разных ядрах, процессорах, серверных нодах и т.д. Это даёт игре возможность содержать тысячи игроков в одном бесшовном мире. В одной локации игрокам обычно запрещают толпиться, но если разрешают, то игру, естественно, может начать трясти в этой локации. Остальные локации должны работать как обычно.
>>32955
Во-первых, серверная симуляция физики сотни управляемых игроками персонажей почти не будет отличаться от симуляции 99 NPC и 1 игрока в чисто однопользовательской, полностью локальной игре. Единственное отличие в том, откуда приходит вся необходимая информация и куда идут результаты. Естественно, что в ММО игроки делятся на группы небольшого размера - симуляция идёт по локациям.
Во-вторых, симуляция на сервере часто значительно медленнее частоты кадров на клиенте: 15 Гц будет достаточно для условной ММОРПГ с автоматически наводящимися на цель навыками. По-моему, даже в соревновательных шутерах используют около 30 Гц. Симуляция на клиенте от 60 Гц и выше нужна ради плавности картинки без лишней интерполяции. Да и массово многопользовательские игры геймплейно оптимизируются: те же самонаводящиеся навыки значительно проще предсказать/интерполировать.
В-третьих, в синглплеере ПК нужно обработать массу информации, зависящей от результатов всего цикла физической симуляции: передвинуть модели, задать анимации, скрыть лишнее и показать нужное и т.д. В мультиплеере этим занимается в основном клиент, а передачу данных сервер может делать параллельно симуляции физики, т.е. нет искусственных задержек.
Короче, серверный CPU по ядру может быть слабее клиентского и при этом не сильно нагружен даже в массовом мультиплеере. Серверу нужны только многопоточность и широкий канал связи.
>>32851
>конечная цель захостить с возможностями:
>- автопоиска соперника для игры
>- создание акков
>>32858
>уровень три в ряд, тоже пошаг
Ты бы лучше больше подробностей рассказал.
Например, сколько игроков в матче? Будут ли у них рейтинги 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-чат только... Остальное знаю из множества каких-то статей про онлайн геймдев.
54 Кб, 400x1000>>32972
Шутник, ты опять нашутил в тред не подумав? Анон правильно говорит: сервер == многопоточность и энергоэффективность, а ещё тонны RAM и PCI-E. Производительность одного ядра в 2 раза ниже, в противном случае датацентры просто сгорали бы. Информация свободно доступна онлайн - изучай.
>>32966
В ММО обычно мир делится на локации, которые обрабатываются параллельно - на разных ядрах, процессорах, серверных нодах и т.д. Это даёт игре возможность содержать тысячи игроков в одном бесшовном мире. В одной локации игрокам обычно запрещают толпиться, но если разрешают, то игру, естественно, может начать трясти в этой локации. Остальные локации должны работать как обычно.
>>32955
Во-первых, серверная симуляция физики сотни управляемых игроками персонажей почти не будет отличаться от симуляции 99 NPC и 1 игрока в чисто однопользовательской, полностью локальной игре. Единственное отличие в том, откуда приходит вся необходимая информация и куда идут результаты. Естественно, что в ММО игроки делятся на группы небольшого размера - симуляция идёт по локациям.
Во-вторых, симуляция на сервере часто значительно медленнее частоты кадров на клиенте: 15 Гц будет достаточно для условной ММОРПГ с автоматически наводящимися на цель навыками. По-моему, даже в соревновательных шутерах используют около 30 Гц. Симуляция на клиенте от 60 Гц и выше нужна ради плавности картинки без лишней интерполяции. Да и массово многопользовательские игры геймплейно оптимизируются: те же самонаводящиеся навыки значительно проще предсказать/интерполировать.
В-третьих, в синглплеере ПК нужно обработать массу информации, зависящей от результатов всего цикла физической симуляции: передвинуть модели, задать анимации, скрыть лишнее и показать нужное и т.д. В мультиплеере этим занимается в основном клиент, а передачу данных сервер может делать параллельно симуляции физики, т.е. нет искусственных задержек.
Короче, серверный CPU по ядру может быть слабее клиентского и при этом не сильно нагружен даже в массовом мультиплеере. Серверу нужны только многопоточность и широкий канал связи.
>>32851
>>32858
Ты бы лучше больше подробностей рассказал.
Например, сколько игроков в матче? Будут ли у них рейтинги Elo? Соревнования? Таблицы рекордов? Специальный чат в глобальном/локальном лобби? Матчмейкинг выбирает кого угодно или оценивает удалённость клиентов друг от друга или их навыки? Создаётся ли игроками особый контент на сервере? Собираешься ли всерьёз монетизировать проект?
Возьмём самый примитивный вариант:
- никаких чатов, рейтингов и таблиц рекордов;
- матчмейкер соединяет первых попавшихся;
- в матче может быть всего лишь два игрока;
- туннелирование будет средствами Steam.
С такими вводными сервер пиши хоть на PHP.
Пример диалога с простейшим REST сервером:
Дальше - общение клиентов через TCP или UDP:
В данном случае оба клиента - 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-чат только... Остальное знаю из множества каких-то статей про онлайн геймдев.
Шутник, ты опять нашутил в тред не подумав? Анон правильно говорит: сервер == многопоточность и энергоэффективность, а ещё тонны RAM и PCI-E. Производительность одного ядра в 2 раза ниже, в противном случае датацентры просто сгорали бы. Информация свободно доступна онлайн - изучай.
>>32966
В ММО обычно мир делится на локации, которые обрабатываются параллельно - на разных ядрах, процессорах, серверных нодах и т.д. Это даёт игре возможность содержать тысячи игроков в одном бесшовном мире. В одной локации игрокам обычно запрещают толпиться, но если разрешают, то игру, естественно, может начать трясти в этой локации. Остальные локации должны работать как обычно.
>>32955
Во-первых, серверная симуляция физики сотни управляемых игроками персонажей почти не будет отличаться от симуляции 99 NPC и 1 игрока в чисто однопользовательской, полностью локальной игре. Единственное отличие в том, откуда приходит вся необходимая информация и куда идут результаты. Естественно, что в ММО игроки делятся на группы небольшого размера - симуляция идёт по локациям.
Во-вторых, симуляция на сервере часто значительно медленнее частоты кадров на клиенте: 15 Гц будет достаточно для условной ММОРПГ с автоматически наводящимися на цель навыками. По-моему, даже в соревновательных шутерах используют около 30 Гц. Симуляция на клиенте от 60 Гц и выше нужна ради плавности картинки без лишней интерполяции. Да и массово многопользовательские игры геймплейно оптимизируются: те же самонаводящиеся навыки значительно проще предсказать/интерполировать.
В-третьих, в синглплеере ПК нужно обработать массу информации, зависящей от результатов всего цикла физической симуляции: передвинуть модели, задать анимации, скрыть лишнее и показать нужное и т.д. В мультиплеере этим занимается в основном клиент, а передачу данных сервер может делать параллельно симуляции физики, т.е. нет искусственных задержек.
Короче, серверный CPU по ядру может быть слабее клиентского и при этом не сильно нагружен даже в массовом мультиплеере. Серверу нужны только многопоточность и широкий канал связи.
>>32851
>конечная цель захостить с возможностями:
>- автопоиска соперника для игры
>- создание акков
>>32858
>уровень три в ряд, тоже пошаг
Ты бы лучше больше подробностей рассказал.
Например, сколько игроков в матче? Будут ли у них рейтинги 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-чат только... Остальное знаю из множества каких-то статей про онлайн геймдев.
>>33441
Интересно когда китайцы начнут делать рефаб материнки по EPYC и новые Xeon
Старые б/у EPYC уже можно купить, они были б охуенны как альтернатива сборкам на 12400-13400
Мимо любитель собирать бомж пк
Интересно когда китайцы начнут делать рефаб материнки по EPYC и новые Xeon
Старые б/у EPYC уже можно купить, они были б охуенны как альтернатива сборкам на 12400-13400
Мимо любитель собирать бомж пк
>>33467
Меню сверху > 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/
>>33449
Проблема в том, что новые серверные процессоры используют какие-то особенные сокеты, поэтому, я подозреваю, делать кастомные платы невыгодно. Выгоднее, наверное, продать сервер целиком.
В теории можно купить б/у "workstation", но там всё сомнительно устаревшее по сравнению с новыми геймерскими ПК, и придётся возиться с дровами.
>>33447
Ты не понял. "Бесшовным" называют мир, в котором перемещение происходит без экрана "Loading...", но технически "швы" присутствуют в любом игровом пространстве достаточно большого размера.
В одиночной игре движок незаметно на фоне читает актуальные данные с диска по кусочкам (чанками), "выгружая" из памяти ставшие лишними кусочки. Телепортация через всю карту потребует "Loading...", поскольку движок не успевает прочитать данные.
В мультиплеере с огромным миром пользователей перебрасывает с одной серверной ноды на другую, распределяя нагрузку на сервер. Естественно, что потребуется хитрый алгоритм запуска и удаления параллельных локаций, чтоб всё было эффективно. Клиентская часть подгружает данные как в сингле.
Иногда можно заметить лёгкий "лаг" при быстром перемещении через невидимую границу, но с т.з. маркетинга мир по-прежнему "бесшовный" - нет прерывания геймплея загрузочным экраном.
Меню сверху > 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/
>>33449
Проблема в том, что новые серверные процессоры используют какие-то особенные сокеты, поэтому, я подозреваю, делать кастомные платы невыгодно. Выгоднее, наверное, продать сервер целиком.
В теории можно купить б/у "workstation", но там всё сомнительно устаревшее по сравнению с новыми геймерскими ПК, и придётся возиться с дровами.
>>33447
Ты не понял. "Бесшовным" называют мир, в котором перемещение происходит без экрана "Loading...", но технически "швы" присутствуют в любом игровом пространстве достаточно большого размера.
В одиночной игре движок незаметно на фоне читает актуальные данные с диска по кусочкам (чанками), "выгружая" из памяти ставшие лишними кусочки. Телепортация через всю карту потребует "Loading...", поскольку движок не успевает прочитать данные.
В мультиплеере с огромным миром пользователей перебрасывает с одной серверной ноды на другую, распределяя нагрузку на сервер. Естественно, что потребуется хитрый алгоритм запуска и удаления параллельных локаций, чтоб всё было эффективно. Клиентская часть подгружает данные как в сингле.
Иногда можно заметить лёгкий "лаг" при быстром перемещении через невидимую границу, но с т.з. маркетинга мир по-прежнему "бесшовный" - нет прерывания геймплея загрузочным экраном.
92 Кб, 1200x995>>33619
Согласен про бесшовность, коме этого:
В истинно бесшовной игре тебе покажут анимацию телепортации, и во время её будет идти подгрузка. Пример: Fallen Order и Survivor, где полёты на звездолёте это по сути та же телепортация, но ты бесшовно заходишь в кабину на одной планете, просишь пилота полететь, смотришь заставку с летящими звёздами из шиндовс 95 в иллюминаторах, и затем бесшовно выходишь на другой планете из корабля. Нам геймдевелоперам вполне очевидно что происходило под капотом, пока игрок всю эту синему созерцал. В 33 потока одна сцена выгружается, вторая загружается.
Согласен про бесшовность, коме этого:
> Телепортация через всю карту потребует "Loading..."
В истинно бесшовной игре тебе покажут анимацию телепортации, и во время её будет идти подгрузка. Пример: Fallen Order и Survivor, где полёты на звездолёте это по сути та же телепортация, но ты бесшовно заходишь в кабину на одной планете, просишь пилота полететь, смотришь заставку с летящими звёздами из шиндовс 95 в иллюминаторах, и затем бесшовно выходишь на другой планете из корабля. Нам геймдевелоперам вполне очевидно что происходило под капотом, пока игрок всю эту синему созерцал. В 33 потока одна сцена выгружается, вторая загружается.
>>33642
Подвох в том, что ты
- это и есть "загрузочный экран", просто в 3D.
Есть разница между:
0. Есть старый ландшафт, он занимает память.
1. Загрузить интерьер корабля, не теряя ландшафт.
2. Закрыть окна корабля "летящими звёздами".
3. Выгрузить старый ландшафт, освободив память.
4. Загрузить новый ландшафт на место старого.
5. Показать новый ландшафт в окнах корабля.
И:
0. Есть старый ландшафт, он занимает память.
1. Загрузить новый ландшафт, не теряя старого.
2. Переместить игрока на новый ландшафт.
3. Выгрузить старый ландшафт.
Суть в том, что "корабль" легче "ландшафта".
А ещё, прерывает ли телепорт корабля геймплей?
Если геймплей - "бегать по ландшафту", то прерывает.
Поэтому телепорт на корабле ≈ загрузочный экран.
Подвох в том, что ты
>заходишь в кабину
- это и есть "загрузочный экран", просто в 3D.
Есть разница между:
0. Есть старый ландшафт, он занимает память.
1. Загрузить интерьер корабля, не теряя ландшафт.
2. Закрыть окна корабля "летящими звёздами".
3. Выгрузить старый ландшафт, освободив память.
4. Загрузить новый ландшафт на место старого.
5. Показать новый ландшафт в окнах корабля.
И:
0. Есть старый ландшафт, он занимает память.
1. Загрузить новый ландшафт, не теряя старого.
2. Переместить игрока на новый ландшафт.
3. Выгрузить старый ландшафт.
Суть в том, что "корабль" легче "ландшафта".
А ещё, прерывает ли телепорт корабля геймплей?
Если геймплей - "бегать по ландшафту", то прерывает.
Поэтому телепорт на корабле ≈ загрузочный экран.
>>32798
Почему так? Неужели программисты деградировали? Разрабатывают языки, но не могут простой редактор смастерить на своём "новом и быстром" языке, лол, полагаясь на выкидыши браузерного инцеста...
Дайте мне машину времени - удалю хромиум у гугла.
>вынужденная необходимость именно им пользоваться сейчас, был бы другой редактор
Почему так? Неужели программисты деградировали? Разрабатывают языки, но не могут простой редактор смастерить на своём "новом и быстром" языке, лол, полагаясь на выкидыши браузерного инцеста...
Дайте мне машину времени - удалю хромиум у гугла.
>>33721
Vs code сильно оптимизирован, я как то сравнивал с разными типа Geany который вообще на с++ - так нифига у них сравнимое потребление. Только у вскода плагинов в разы больше и делать их проще.
Vs code сильно оптимизирован, я как то сравнивал с разными типа Geany который вообще на с++ - так нифига у них сравнимое потребление. Только у вскода плагинов в разы больше и делать их проще.
>>32938
ну мне опять же не нужно прогнозирование никакое. у меня пошаг пошаговый.
не понял, ну как скажешь.
>>33441
2.
было бы круто.
нет.
по скилу - было бы круто. по расстоянию - не знаю. можно ради опыта такое попробовать написать. по сути только матчмейкинг надо будет переписывать если что?
не понял, ну вроде нет.
сложный вопрос. попробовать можно. но я понимаю что это уже вообще отдельный мир. бизнес короче.
я так изначально это и представлял, потому что это более правильным кажется.
пока начал совсем с малого.
ну мне опять же не нужно прогнозирование никакое. у меня пошаг пошаговый.
>настоящих
не понял, ну как скажешь.
>>33441
>сколько игроков в матче?
2.
>Будут ли у них рейтинги Elo? Соревнования? Таблицы рекордов?
было бы круто.
>Специальный чат в глобальном/локальном лобби?
нет.
>Матчмейкинг выбирает кого угодно или оценивает удалённость клиентов друг от друга или их навыки?
по скилу - было бы круто. по расстоянию - не знаю. можно ради опыта такое попробовать написать. по сути только матчмейкинг надо будет переписывать если что?
>Создаётся ли игроками особый контент на сервере?
не понял, ну вроде нет.
>Собираешься ли всерьёз монетизировать проект?
сложный вопрос. попробовать можно. но я понимаю что это уже вообще отдельный мир. бизнес короче.
>А если хочешь сделать рейтинги, таблицы со 100% честными рекордами, соревнования и так далее, то полагаться на описанное выше решение уже нельзя. Потребуется крутить на сервере все матчи по шагам, проверяя легитимность действий игроков и всё это записывая в БД в подробностях для статистики.
я так изначально это и представлял, потому что это более правильным кажется.
пока начал совсем с малого.
26 Кб, 404x405кто-нибудь пробовал сделать что-то вроде esc архитектуры? как вы примерно это делали, чтобы оптимизировать всё до нормального состояния?
я попробовал сделать, но выглядит всё мудрёно, доступ к компонентам сущности выходит мега душный, по сути перебираются ноды в одной "папке" у "сущности", плюс в этой же "сущности" лежит прочая ерунда, которая нужна для функционирования игрового объекта, но пользоваться этим откровенно неудобно, постоянно приходится искать нужную ноду или перебирать "компоненты" в папке
я попробовал сделать, но выглядит всё мудрёно, доступ к компонентам сущности выходит мега душный, по сути перебираются ноды в одной "папке" у "сущности", плюс в этой же "сущности" лежит прочая ерунда, которая нужна для функционирования игрового объекта, но пользоваться этим откровенно неудобно, постоянно приходится искать нужную ноду или перебирать "компоненты" в папке
>>34045
Если тебе неудобно, то не делай. Поскольку такой подход не даст какого то большого ускорения (это не c++ ecs модуль например), то имеет смысл только если это как то упрощает разработку твоей игры. В моем жанре например проще использовать паттерны Action, Command, ecs-лайк я попробовал и отказался.
Если тебе неудобно, то не делай. Поскольку такой подход не даст какого то большого ускорения (это не c++ ecs модуль например), то имеет смысл только если это как то упрощает разработку твоей игры. В моем жанре например проще использовать паттерны Action, Command, ecs-лайк я попробовал и отказался.
>>34054
для навыков, чтобы они были разнообразные, я пока что не нашёл других вариантов, но я уже подумал, что для мобов и всего остального не использовать как вариант, ещё посмотрю твои паттерны, может подойдёт что-то, спасибо
для навыков, чтобы они были разнообразные, я пока что не нашёл других вариантов, но я уже подумал, что для мобов и всего остального не использовать как вариант, ещё посмотрю твои паттерны, может подойдёт что-то, спасибо
>>34045
Иногда компоненты это просто компоненты. Безо всяких ецс архитектур. Подумай над этим.
Иногда компоненты это просто компоненты. Безо всяких ецс архитектур. Подумай над этим.
>>34066
блин а реально...
блин а реально...
>>34045 >>34061
Делай просто через композицию/агрегацию ООП.
Пример, как сделать тулбар с выбором орудий:
Player + ToolBelt - это композиция (нельзя менять).
ToolBelt + Shovel - это агрегация (можно менять).
Player отвечает только за движение и ToolBelt.
ToolBelt отвечает за переключение орудий:
Дальше орудие само делает всё, что ему нужно:
Обработчики _input, _process и т.д. отключаемы:
И т.д. Это снизит нагрузку в рантайме.
Если нужны простые навыки как в TF2, Overwatch, Genshin Impact и т.п., тогда ToolBelt не нужен и ты можешь просто сделать всё через композицию. Конкретные клавиши навыков биндятся через инспектор, например, можно так:
Делай просто через композицию/агрегацию ООП.
Пример, как сделать тулбар с выбором орудий:
>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: # применяем способность...
>>34045 >>34061
Делай просто через композицию/агрегацию ООП.
Пример, как сделать тулбар с выбором орудий:
Player + ToolBelt - это композиция (нельзя менять).
ToolBelt + Shovel - это агрегация (можно менять).
Player отвечает только за движение и ToolBelt.
ToolBelt отвечает за переключение орудий:
Дальше орудие само делает всё, что ему нужно:
Обработчики _input, _process и т.д. отключаемы:
И т.д. Это снизит нагрузку в рантайме.
Если нужны простые навыки как в TF2, Overwatch, Genshin Impact и т.п., тогда ToolBelt не нужен и ты можешь просто сделать всё через композицию. Конкретные клавиши навыков биндятся через инспектор, например, можно так:
Делай просто через композицию/агрегацию ООП.
Пример, как сделать тулбар с выбором орудий:
>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: # применяем способность...
>>34061
Мне проще через код/json, хоть я и много лет сопротивлялся этому. Но игра сложнее среднего, поэтому мне нет смысла конфигурировать мобов через нодовый визуальный редактор.
Мне проще через код/json, хоть я и много лет сопротивлялся этому. Но игра сложнее среднего, поэтому мне нет смысла конфигурировать мобов через нодовый визуальный редактор.
>>34140
Да, думаю первое как раз хорошо подходит по концепции, только toolbelt будет самим навыком, а его содержимое действиями, и последовательно их все выполнить, плюс можно динамически изменять их в процессе, наверно это наилучший способ, спасибо большое
Да, думаю первое как раз хорошо подходит по концепции, только toolbelt будет самим навыком, а его содержимое действиями, и последовательно их все выполнить, плюс можно динамически изменять их в процессе, наверно это наилучший способ, спасибо большое
>>34149
Покажи похожие игры из популярных.
>>34166
Что это за "навыки", которые состоят из действий, выполняющихся последовательно? Типа "запустить ракету/мячик/бумеранг, которая может выпустить зажигательный/замораживающий эффект, который действует по цели/по области/веером/дождём и уничтожается сразу/по таймеру/от сопротивления"?
Просто интересно. Обычно "навык" - одно действие.
>игра сложнее среднего
Покажи похожие игры из популярных.
>>34166
>действиями, и последовательно их все выполнить
Что это за "навыки", которые состоят из действий, выполняющихся последовательно? Типа "запустить ракету/мячик/бумеранг, которая может выпустить зажигательный/замораживающий эффект, который действует по цели/по области/веером/дождём и уничтожается сразу/по таймеру/от сопротивления"?
Просто интересно. Обычно "навык" - одно действие.
>>34305
_physics_process идет отдельно от фпс, как правило с фиксированным 60 тиков/сек, в настройках проекта это указывается. А если ты про дельту, то это другое, и так везде, просто где-то под капотом, где-то не.
_physics_process идет отдельно от фпс, как правило с фиксированным 60 тиков/сек, в настройках проекта это указывается. А если ты про дельту, то это другое, и так везде, просто где-то под капотом, где-то не.
>>34305
Не привязан, но есть нюанс...
Если твоя игра лагает из-за графики (даже если вся нагрузка на видеокарту шейдерами) - физика тоже затормозит. Если лагает из-за физики (очень много ригидбоди сталкиваются друг с другом) - графика затормозит. Поэтому везде нужно учитывать delta.
Вроде бы пытаются полностью отвязать физику от графики многопоточностью, но она нестабильна...
Не привязан, но есть нюанс...
Если твоя игра лагает из-за графики (даже если вся нагрузка на видеокарту шейдерами) - физика тоже затормозит. Если лагает из-за физики (очень много ригидбоди сталкиваются друг с другом) - графика затормозит. Поэтому везде нужно учитывать delta.
Вроде бы пытаются полностью отвязать физику от графики многопоточностью, но она нестабильна...
>>34318
А шо если резать резолюшн скейл, когда фпс начнет дропать ниже нужного значения? Правда не везде так легко получить отдельно цпу дельта и гпу дельта. Но если удается это сделать, то вот оно, стабильный геймплей со стабильным значением фпсов, даже если игра внезапно высралась огромным количеством дроуколлов.
>Если твоя игра лагает из-за графики (даже если вся нагрузка на видеокарту шейдерами) - физика тоже затормозит. Если лагает из-за физики (очень много ригидбоди сталкиваются друг с другом) - графика затормозит. Поэтому везде нужно учитывать delta.
А шо если резать резолюшн скейл, когда фпс начнет дропать ниже нужного значения? Правда не везде так легко получить отдельно цпу дельта и гпу дельта. Но если удается это сделать, то вот оно, стабильный геймплей со стабильным значением фпсов, даже если игра внезапно высралась огромным количеством дроуколлов.
>>34318
А, и GDScript по умолчанию работает в один поток. А следовательно, код в _process и _physic_process будет происходить всегда последовательно и если одна из функций тормозит, другая будет запаздывать.
Работать с многопоточно сложно, особенно когда данные разбросаны и нужны в нескольких потоках.
Ещё и дерево сцены - это (пока что) один поток...
А, и GDScript по умолчанию работает в один поток. А следовательно, код в _process и _physic_process будет происходить всегда последовательно и если одна из функций тормозит, другая будет запаздывать.
Работать с многопоточно сложно, особенно когда данные разбросаны и нужны в нескольких потоках.
Ещё и дерево сцены - это (пока что) один поток...
>>34321
Видел такую фичу в каких-то играх на юнити. Как-то особенного ускорения не заметил. Уж лучше я буду страдать от 20 фпс, чем от пикселей на весь экран.
Да, но тогда игра в самые напряжённые моменты (огромная толпа врагов окруживших игрока) будет внезапно либо "рассыпаться на пиксели", либо искажаться артефактами линейной интерполяции.
Видеокарты RTX 30/40/50 вроде позиционировали "ускоряющими рендер с помощью ИИ", и вот там рендеринг идёт в маленьком разрешении и потом растягивается с помощью какой-то нейронки, что заблюривает все мелкие детали в кинцо-мыльцо.
Возникает вопрос, нужны ли такие оптимизации?
А если нужны, не лучше ли урезать графику? Ну не используйте 4К текстуры, если у вас игра начинает тормозить и скукоживается до 360p с нейронкой...
Посмотри класс Performance, там должно быть.
https://docs.godotengine.org/en/stable/classes/class_performance.html#enum-performance-monitor
>резать резолюшн скейл
Видел такую фичу в каких-то играх на юнити. Как-то особенного ускорения не заметил. Уж лучше я буду страдать от 20 фпс, чем от пикселей на весь экран.
>геймплей со стабильным значением фпсов
Да, но тогда игра в самые напряжённые моменты (огромная толпа врагов окруживших игрока) будет внезапно либо "рассыпаться на пиксели", либо искажаться артефактами линейной интерполяции.
Видеокарты RTX 30/40/50 вроде позиционировали "ускоряющими рендер с помощью ИИ", и вот там рендеринг идёт в маленьком разрешении и потом растягивается с помощью какой-то нейронки, что заблюривает все мелкие детали в кинцо-мыльцо.
Возникает вопрос, нужны ли такие оптимизации?
А если нужны, не лучше ли урезать графику? Ну не используйте 4К текстуры, если у вас игра начинает тормозить и скукоживается до 360p с нейронкой...
>получить отдельно цпу дельта и гпу дельта
Посмотри класс Performance, там должно быть.
https://docs.godotengine.org/en/stable/classes/class_performance.html#enum-performance-monitor
>>34321
Алсо, есть один нюанс:
Draw call - это буквально вызов GPU API из CPU. Т.е. совершенно не важно количество пикселей, ведь замедление происходит из-за общения CPU с GPU.
Уменьшение разрешения экрана может помочь, если определённый шейдер загружает GPU на 100%. Т.е. уменьшая количество пикселей можно уменьшить количество вызовов этого шейдера на стороне GPU. Соответственно GPU станет доступна CPU раньше.
Но опять же, лучше упростить код шейдера или его полностью отключить, чем скукоживать картинку... Скукоженная картинка с любым шейдером плохая.
Алсо, есть один нюанс:
>высралась огромным количеством дроуколлов
Draw call - это буквально вызов GPU API из CPU. Т.е. совершенно не важно количество пикселей, ведь замедление происходит из-за общения CPU с GPU.
Уменьшение разрешения экрана может помочь, если определённый шейдер загружает GPU на 100%. Т.е. уменьшая количество пикселей можно уменьшить количество вызовов этого шейдера на стороне GPU. Соответственно GPU станет доступна CPU раньше.
Но опять же, лучше упростить код шейдера или его полностью отключить, чем скукоживать картинку... Скукоженная картинка с любым шейдером плохая.
>>34332
Окей. Начинаю.
Окей. Начинаю.
>>34339
У меня фантазии нет самому что-то придумывать.
Можешь глянуть всякие children of morta, moonlighter, да и их дохуя подобных, айзека и то можно за яйца притянуть, сюжет то есть. Типа сюжет и развитие персов какое-то между посещениям рогаликовских данжей.
У меня фантазии нет самому что-то придумывать.
>Так РПГ (сюжет) или рогалик (дрочь механик)?
Можешь глянуть всякие children of morta, moonlighter, да и их дохуя подобных, айзека и то можно за яйца притянуть, сюжет то есть. Типа сюжет и развитие персов какое-то между посещениям рогаликовских данжей.
>>34341
Это может называться rogue-lite.
Формально, "рогалик" (rogue-like) - это только те игры, которые соответствуют строгому определению... Но ньюфаги его запачкали, тыкая в каждую игру. Прост истинных рогаликов (которые ASCII) зумеры боятся.
Rogue-lite - это игры с элементами рогалика, но как минимум по одному параметру не соответствуют определению рогалика. Чаще всего там отсутствует пермасмерть и присутствует 2D/3D графика, и ещё последнее время стало популярным делать игру в реальном времени вместо пошаговости... Короче, от рогаликов в рогулайтах почти ничего не осталось.
Есть ещё понятие "dungeon crawler" - это вид РПГ, где необходимо исследовать подземелья с монстрами. Рогалики и некоторые рогулайты эти подземелья процедурно генерируют, так что они являются РПГ разновидности "dungeon crawler", но с жёсткими (у рогулайтов - не очень) жанровыми рамками.
Но в то же время к "РПГ" чаще относят игры с более определённым линейным сюжетом, особенно jRPG.
Короч, "РПГ-рогалик в сеттинге данжа" - это фраза из разряда "масляное масло с наполнителем из масла".
Это может называться rogue-lite.
Формально, "рогалик" (rogue-like) - это только те игры, которые соответствуют строгому определению... Но ньюфаги его запачкали, тыкая в каждую игру. Прост истинных рогаликов (которые ASCII) зумеры боятся.
Rogue-lite - это игры с элементами рогалика, но как минимум по одному параметру не соответствуют определению рогалика. Чаще всего там отсутствует пермасмерть и присутствует 2D/3D графика, и ещё последнее время стало популярным делать игру в реальном времени вместо пошаговости... Короче, от рогаликов в рогулайтах почти ничего не осталось.
Есть ещё понятие "dungeon crawler" - это вид РПГ, где необходимо исследовать подземелья с монстрами. Рогалики и некоторые рогулайты эти подземелья процедурно генерируют, так что они являются РПГ разновидности "dungeon crawler", но с жёсткими (у рогулайтов - не очень) жанровыми рамками.
Но в то же время к "РПГ" чаще относят игры с более определённым линейным сюжетом, особенно jRPG.
Короч, "РПГ-рогалик в сеттинге данжа" - это фраза из разряда "масляное масло с наполнителем из масла".
>>34356
Этот шарит. Налил бы тебе масла в твою масленку, если понимаешь о чем я.
Этот шарит. Налил бы тебе масла в твою масленку, если понимаешь о чем я.
>>34356
Ну, я понимаю рогалик как роглайт тогда. Хоть мне и 34 я соглашусь с зумерами, православных аски рогаликов не видел и чето не хочется после твоего описания, собственно даже любителем роглайтов не являюсь. В общем будет средневековый не рогалик, а чето типа мунлайтера.
Ну, я понимаю рогалик как роглайт тогда. Хоть мне и 34 я соглашусь с зумерами, православных аски рогаликов не видел и чето не хочется после твоего описания, собственно даже любителем роглайтов не являюсь. В общем будет средневековый не рогалик, а чето типа мунлайтера.
236 Кб, 707x270>>34302
Ну вроде того, да, или даже я больше ориентировался на систему карт в slay the spire, или всяких доталайк вроде пикрил
То есть, допустим, навык должен наносить урон, отравлять врага и менять активного персонажа, или вешать дебафф и на врагов, и на союзников, или что угодно, в общем, надо систему, предоставляющую большую возможность комбинирования
Как пример навыка, будут примерно такие действия внутри я думаю:
- кликабельный на врага (открывает возможность нажать на врага, добавляет в массив "получателей" нажатого врага)
- уменьшить очки действия игрока (допустим у каждого навыка есть значение стоимости)
- нанести урон (применяется к каждому получателю в массиве)
- повесить дебафф (применяется к каждому получателю в массиве)
Или допустим массовый навык:
- уменьшить очки действия игрока
- выбрать всех врагов(добавляет всех врагов в массив "получателей")
- нанести урон случайному получателю в массиве 1 раз X3 раза
- повесить дебафф с длительностью, пропорциональной размеру массива "получателей"
- нанести урон игроку
И навык при использовании должен запустить цепочку компонентов по очереди
Возможно, есть что-то более простое для таких штук, я пока что не придумал/не продумал
> Что это за "навыки", которые состоят из действий, выполняющихся последовательно? Типа "запустить ракету/мячик/бумеранг, которая может выпустить зажигательный/замораживающий эффект, который действует по цели/по области/веером/дождём и уничтожается сразу/по таймеру/от сопротивления"?
Ну вроде того, да, или даже я больше ориентировался на систему карт в slay the spire, или всяких доталайк вроде пикрил
То есть, допустим, навык должен наносить урон, отравлять врага и менять активного персонажа, или вешать дебафф и на врагов, и на союзников, или что угодно, в общем, надо систему, предоставляющую большую возможность комбинирования
Как пример навыка, будут примерно такие действия внутри я думаю:
- кликабельный на врага (открывает возможность нажать на врага, добавляет в массив "получателей" нажатого врага)
- уменьшить очки действия игрока (допустим у каждого навыка есть значение стоимости)
- нанести урон (применяется к каждому получателю в массиве)
- повесить дебафф (применяется к каждому получателю в массиве)
Или допустим массовый навык:
- уменьшить очки действия игрока
- выбрать всех врагов(добавляет всех врагов в массив "получателей")
- нанести урон случайному получателю в массиве 1 раз X3 раза
- повесить дебафф с длительностью, пропорциональной размеру массива "получателей"
- нанести урон игроку
И навык при использовании должен запустить цепочку компонентов по очереди
Возможно, есть что-то более простое для таких штук, я пока что не придумал/не продумал
>>34385 (Del)
Отсутствие анального зонда от корпов
Если корпы захотят задним числом изменить лицению, то на юнити и уе тебе пизда
На годоте такое невозможно
>Нахуя нужен Godot, если есть анрил или юнити ? Какие преимущества я получу ?
Отсутствие анального зонда от корпов
Если корпы захотят задним числом изменить лицению, то на юнити и уе тебе пизда
На годоте такое невозможно
>>34385 (Del)
Моя причина - для одинокого анскильного хрыча лучше подходит. Юнька и уе либо для молодых и шутливых, либо для команд, которые нацелены из этих монстров все до последней капли выжимать и драться на мечах за правильность. А я тем времени на годоте клиент для чатагпт вон сделал и почти не стыжусь этого.
Моя причина - для одинокого анскильного хрыча лучше подходит. Юнька и уе либо для молодых и шутливых, либо для команд, которые нацелены из этих монстров все до последней капли выжимать и драться на мечах за правильность. А я тем времени на годоте клиент для чатагпт вон сделал и почти не стыжусь этого.
>>34385 (Del)
По сравнению с несвободными условно-бесплатными и платными движками (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. Потенциал развития в коммерческом плане (использовался даже в автомобилях).
Недостатки - как у любого бесплатного свободного программного обеспечения...
>Какие преимущества
По сравнению с несвободными условно-бесплатными и платными движками (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. Потенциал развития в коммерческом плане (использовался даже в автомобилях).
Недостатки - как у любого бесплатного свободного программного обеспечения...
>>34385 (Del)
По сравнению с несвободными условно-бесплатными и платными движками (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. Потенциал развития в коммерческом плане (использовался даже в автомобилях).
Недостатки - как у любого бесплатного свободного программного обеспечения...
>Какие преимущества
По сравнению с несвободными условно-бесплатными и платными движками (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. Потенциал развития в коммерческом плане (использовался даже в автомобилях).
Недостатки - как у любого бесплатного свободного программного обеспечения...
>>34390
Может ли игрок сам (через GUI) составлять комбинации из этих действий?
Если игрок не может ничего изменить, т.е. это не песочница "сделай сам", тогда тебе нужен будет баланс в игре. А баланс строится вокруг какой-то структуры... Даже если ты можешь технически соединить любые действия в любом порядке, странные комбинации могут сильно нарушать баланс и дезориентировать игрока. Например, очки действий должны учитываться в какой-то фиксированный момент, скажем, сразу после использования навыка; клик на врага или товарища должен всегда приводить к урону/лечению/баффу/дебаффу, а не к чему-то неожиданному; урон игроку должен приходить в одно и то же время у всех навыков и т.д.
С точки зрения балансирования игры проще предсказывать исход боя, когда все навыки следуют какой-то заранее известной формуле урона, а у всех персонажей одна заранее известная формула защиты. Так проще построить графики и вести расчёты в табличках.
С точки зрения геймплея игроку проще понять, что делает только что открытый им навык, проще встроить его в свой стиль игры, проще запомнить и использовать комбинации. Не нужно запоминать "исключения", сформированные против общей структуры навыков.
Абсолютная свобода может быть нужна только если игра позволяет игроку делать любые, даже бессмысленные комбинации, в каком-нибудь симуляторе боя, где герои сами все эти способности используют и этим доставляют удовольствие (игра без игрока). Это аналогично встроенному в игру редактору карт - если б не редактор, карты могли бы представлять из себя статичную 2D картинку/3D меш, но из-за редактора их нужно разбивать на тайлы/кубы. При этом ради высокой гибкости редактора карты мы жертвуем красотой цельной картинки, а для более продвинутого редактора придётся много чего изобретать с нуля...
В общем, подумай, так ли уж тут нужна гибкость? Я бы сделал так:
Этого должно хватить для 99% игр с "навыками". Геймплей зависит только от заданных значений, но даже их достаточно для высокой вариативности. Порядок действий задан фиксированным кодом, что гарантирует предсказуемость в будущем.
Из личного опыта, написать код в одном месте всегда проще, чем делать несколько независимых компонентов и потом их где-то склеивать, а потом искать и разбираться, где и почему что-то отваливается и не работает. При этом разделить связанный в одном месте код не так уж сложно, если он уже работает и его легко проверить (запустив сцену на выполнение). А в инди геймдеве важнее всего добиться рабочего (играбельного) прототипа любой ценой в кратчайшие сроки... Код прототипа не обязательно потом использовать где-либо. Важно только экспериментально доказать работоспособность возникших идей, а всё остальное решается рефакторингом. Иначе можно погрязнуть в оптимизации "самой гибкой в мире" системы и так и не добраться до играбельного прототипа желаемых идей. Конечно, если вся твоя идея игры не заключается в "сделать самую гибкую в мире систему навыков"...
>надо систему, предоставляющую большую возможность комбинирования
Может ли игрок сам (через 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% игр с "навыками". Геймплей зависит только от заданных значений, но даже их достаточно для высокой вариативности. Порядок действий задан фиксированным кодом, что гарантирует предсказуемость в будущем.
Из личного опыта, написать код в одном месте всегда проще, чем делать несколько независимых компонентов и потом их где-то склеивать, а потом искать и разбираться, где и почему что-то отваливается и не работает. При этом разделить связанный в одном месте код не так уж сложно, если он уже работает и его легко проверить (запустив сцену на выполнение). А в инди геймдеве важнее всего добиться рабочего (играбельного) прототипа любой ценой в кратчайшие сроки... Код прототипа не обязательно потом использовать где-либо. Важно только экспериментально доказать работоспособность возникших идей, а всё остальное решается рефакторингом. Иначе можно погрязнуть в оптимизации "самой гибкой в мире" системы и так и не добраться до играбельного прототипа желаемых идей. Конечно, если вся твоя идея игры не заключается в "сделать самую гибкую в мире систему навыков"...
>>34390
Может ли игрок сам (через GUI) составлять комбинации из этих действий?
Если игрок не может ничего изменить, т.е. это не песочница "сделай сам", тогда тебе нужен будет баланс в игре. А баланс строится вокруг какой-то структуры... Даже если ты можешь технически соединить любые действия в любом порядке, странные комбинации могут сильно нарушать баланс и дезориентировать игрока. Например, очки действий должны учитываться в какой-то фиксированный момент, скажем, сразу после использования навыка; клик на врага или товарища должен всегда приводить к урону/лечению/баффу/дебаффу, а не к чему-то неожиданному; урон игроку должен приходить в одно и то же время у всех навыков и т.д.
С точки зрения балансирования игры проще предсказывать исход боя, когда все навыки следуют какой-то заранее известной формуле урона, а у всех персонажей одна заранее известная формула защиты. Так проще построить графики и вести расчёты в табличках.
С точки зрения геймплея игроку проще понять, что делает только что открытый им навык, проще встроить его в свой стиль игры, проще запомнить и использовать комбинации. Не нужно запоминать "исключения", сформированные против общей структуры навыков.
Абсолютная свобода может быть нужна только если игра позволяет игроку делать любые, даже бессмысленные комбинации, в каком-нибудь симуляторе боя, где герои сами все эти способности используют и этим доставляют удовольствие (игра без игрока). Это аналогично встроенному в игру редактору карт - если б не редактор, карты могли бы представлять из себя статичную 2D картинку/3D меш, но из-за редактора их нужно разбивать на тайлы/кубы. При этом ради высокой гибкости редактора карты мы жертвуем красотой цельной картинки, а для более продвинутого редактора придётся много чего изобретать с нуля...
В общем, подумай, так ли уж тут нужна гибкость? Я бы сделал так:
Этого должно хватить для 99% игр с "навыками". Геймплей зависит только от заданных значений, но даже их достаточно для высокой вариативности. Порядок действий задан фиксированным кодом, что гарантирует предсказуемость в будущем.
Из личного опыта, написать код в одном месте всегда проще, чем делать несколько независимых компонентов и потом их где-то склеивать, а потом искать и разбираться, где и почему что-то отваливается и не работает. При этом разделить связанный в одном месте код не так уж сложно, если он уже работает и его легко проверить (запустив сцену на выполнение). А в инди геймдеве важнее всего добиться рабочего (играбельного) прототипа любой ценой в кратчайшие сроки... Код прототипа не обязательно потом использовать где-либо. Важно только экспериментально доказать работоспособность возникших идей, а всё остальное решается рефакторингом. Иначе можно погрязнуть в оптимизации "самой гибкой в мире" системы и так и не добраться до играбельного прототипа желаемых идей. Конечно, если вся твоя идея игры не заключается в "сделать самую гибкую в мире систему навыков"...
>надо систему, предоставляющую большую возможность комбинирования
Может ли игрок сам (через 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% игр с "навыками". Геймплей зависит только от заданных значений, но даже их достаточно для высокой вариативности. Порядок действий задан фиксированным кодом, что гарантирует предсказуемость в будущем.
Из личного опыта, написать код в одном месте всегда проще, чем делать несколько независимых компонентов и потом их где-то склеивать, а потом искать и разбираться, где и почему что-то отваливается и не работает. При этом разделить связанный в одном месте код не так уж сложно, если он уже работает и его легко проверить (запустив сцену на выполнение). А в инди геймдеве важнее всего добиться рабочего (играбельного) прототипа любой ценой в кратчайшие сроки... Код прототипа не обязательно потом использовать где-либо. Важно только экспериментально доказать работоспособность возникших идей, а всё остальное решается рефакторингом. Иначе можно погрязнуть в оптимизации "самой гибкой в мире" системы и так и не добраться до играбельного прототипа желаемых идей. Конечно, если вся твоя идея игры не заключается в "сделать самую гибкую в мире систему навыков"...
Опять кормите?
>>34385 (Del)
Получишь ты свой репорт.
Получишь ты свой репорт.
>>34398
В целом да, но для пущей гибкости компоненты наследуешь от белой ноды, и лепишь их прямо в дерево прямо как чайлды объектов, которым требуется композиция. В итоге получаешь и скорость разработки прототипа и будущий рефакторинг упрощается. Вот пример: https://www.youtube.com/watch?v=JJruVWtTXqA
В целом да, но для пущей гибкости компоненты наследуешь от белой ноды, и лепишь их прямо в дерево прямо как чайлды объектов, которым требуется композиция. В итоге получаешь и скорость разработки прототипа и будущий рефакторинг упрощается. Вот пример: https://www.youtube.com/watch?v=JJruVWtTXqA
>>34398
Не через сам GUI, но определенным образом может, собрав модификаторы другого плана, допустим, раса персонажа игрока стала "очень крутой", и навыки должны начать работать немного по-другому, допустим, после каждого нанесения урона должен накладываться дебафф, все прямые нанесения урона наносят урон 2 раза по половине от начального, а любое лечение сверх максимального хп спавнит дополнительного союзника, либо, если он уже есть, увеличивает его хп, и т.д.
В плане концепции у игрока чаще всего будет мало навыков, а одновременно в одном бою из всех навыков он сможет использовать до 5-6, причём, слот навыка может заменять пассивка, поэтому ему должна быть доступна модификация навыков в той или иной степени, чтобы было возможным побеждать с 3-4 навыками или даже проходить игру со стартовыми способностями + прочие модификаторы
Про вариант с кодом в одном месте, мне кажется, будет сложнее делать какие-то модификации, допустим:
1) есть действие обычной атаки
2) есть действие, которое наносит урон N раз, где N - количество врагов, оно добавляет в очередь действий N действий обычной атаки
3) есть действие, которое заменяет все обычные атаки на наложение дебаффа
И допустим игрок получил навык с действием 2, после модифицировал навык действием 3, после чего действие 2 должно начать не наносить урон N раз, а накладывать дебафф N раз
мне кажется, сделав папку с кучей сцен, которые будут представлять определенные действия, и потом слепляя это в навыки, можно будет и быстрее понять, что навык из себя представляет, и модифицировать в процессе, и даже в дебаг режиме посмотреть, во что он будет превращаться с теми или иными модификаторами
В целом, в концепте есть некоторая поломка баланса игроком вроде the binding of isaac, но строиться будет не только на подбираемых предметах
> Может ли игрок сам (через GUI) составлять комбинации из этих действий?
Не через сам GUI, но определенным образом может, собрав модификаторы другого плана, допустим, раса персонажа игрока стала "очень крутой", и навыки должны начать работать немного по-другому, допустим, после каждого нанесения урона должен накладываться дебафф, все прямые нанесения урона наносят урон 2 раза по половине от начального, а любое лечение сверх максимального хп спавнит дополнительного союзника, либо, если он уже есть, увеличивает его хп, и т.д.
В плане концепции у игрока чаще всего будет мало навыков, а одновременно в одном бою из всех навыков он сможет использовать до 5-6, причём, слот навыка может заменять пассивка, поэтому ему должна быть доступна модификация навыков в той или иной степени, чтобы было возможным побеждать с 3-4 навыками или даже проходить игру со стартовыми способностями + прочие модификаторы
Про вариант с кодом в одном месте, мне кажется, будет сложнее делать какие-то модификации, допустим:
1) есть действие обычной атаки
2) есть действие, которое наносит урон N раз, где N - количество врагов, оно добавляет в очередь действий N действий обычной атаки
3) есть действие, которое заменяет все обычные атаки на наложение дебаффа
И допустим игрок получил навык с действием 2, после модифицировал навык действием 3, после чего действие 2 должно начать не наносить урон N раз, а накладывать дебафф N раз
мне кажется, сделав папку с кучей сцен, которые будут представлять определенные действия, и потом слепляя это в навыки, можно будет и быстрее понять, что навык из себя представляет, и модифицировать в процессе, и даже в дебаг режиме посмотреть, во что он будет превращаться с теми или иными модификаторами
В целом, в концепте есть некоторая поломка баланса игроком вроде the binding of isaac, но строиться будет не только на подбираемых предметах
Я лишь несколько недель учусь и меня не оставляет в покое вопрос. Как лучше - скрипты рядом со сценами (мб еще в кучу и ассеты укладывать), или скрипты отдельно, сцены отдельно, ассеты отдельно? Все вроде как делают в кучу из обучающих видосов, а меня как-то корежит, когда рядом с кодом валяется не код. При этом сам годот автовыставлением путей тоже намекает на первый вариант.
>>34441
Это хорошо только для уникальных нод...
Не забывай, что у нод есть своя цена.
>>34444
Ты хочешь ради этого менять структуру/состояние компонентов всех навыков персонажа, верно? Это выглядит неэффективно... Я бы добавил концепцию модификатора урона: навыки сами по себе никак не меняются, но к ним применяются доп. действия.
Тогда получается что-то вроде:
1. Навык генерирует урон по цели.
2. Урон передаётся вверх к владельцу.
3. Владелец добавляет к нему бонус расы.
4. Владелец отправляет урон назначенной цели.
Имхо, это лучше, чем как-то менять все навыки... Независимо от того, можно ли менять навыки.
Слот в GUI ≠ слот в программной структуре объекта. Пассивные эффекты могут быть в другом месте...
Речь шла о том, чтоб сделать ПРОТОТИП.
Вот ты сейчас можешь поиграть в свою игру? На компьютере, а не в своих фантазиях. Потому что на данный момент твоё описание выглядит как чистая фантазия "было бы круто давать бонус вампиризма вампиру, и чтоб каждая атака накладывала дебафф". Сложность геймдизайна в том, чтобы узнать, что из фантазий реально работает на пользу, а что лишь отвлекает от главной задачи и игрока, и разраба.
Конечно же, сделав гибкую систему навыков ты в будущем сможешь налепить любые навыки. Но тут ключевое слово "будущее", что может никогда и не наступить для твоей идеи игры... А вдруг ты потом обнаружишь, что всё фигня и достаточно лупить единственной оптимальной атакой? Потраченное на бесполезную разработку время уже не вернуть.
Короче, если ты ещё не сделал рабочий прототип, сфокусируйся на минимальном геймплее вроде:
- 1 герой со статичной аватаркой-затычкой;
- 2-3 типа врага со статичным спрайтом;
- 2-3 типа атаки, 2-3 типа дебаффа;
- 2-3 локации для навигации;
- конечная цель геймплея;
- базовые менюшечки.
Потом уже будешь ломать голову над тем, как это расширять и чем расширять интереснее всего. Даже минимальный геймплей луп задолбаешься делать...
Просто говорю по опыту, как тот, кто постоянно себе выдумывал какие-то расширяемые велосипеды, но в результате никак их ни к чему не применил и бросил. Потому что игра важнее каких-то мудрёных систем.
>наследуешь от белой ноды
Это хорошо только для уникальных нод...
Не забывай, что у нод есть своя цена.
>>34444
>допустим, после каждого нанесения урона должен накладываться дебафф, все прямые нанесения урона наносят урон 2 раза по половине от начального, а любое лечение сверх максимального хп спавнит дополнительного союзника
Ты хочешь ради этого менять структуру/состояние компонентов всех навыков персонажа, верно? Это выглядит неэффективно... Я бы добавил концепцию модификатора урона: навыки сами по себе никак не меняются, но к ним применяются доп. действия.
Тогда получается что-то вроде:
1. Навык генерирует урон по цели.
2. Урон передаётся вверх к владельцу.
3. Владелец добавляет к нему бонус расы.
4. Владелец отправляет урон назначенной цели.
Имхо, это лучше, чем как-то менять все навыки... Независимо от того, можно ли менять навыки.
>слот навыка может заменять пассивка
Слот в GUI ≠ слот в программной структуре объекта. Пассивные эффекты могут быть в другом месте...
>сложнее делать какие-то модификации
Речь шла о том, чтоб сделать ПРОТОТИП.
Вот ты сейчас можешь поиграть в свою игру? На компьютере, а не в своих фантазиях. Потому что на данный момент твоё описание выглядит как чистая фантазия "было бы круто давать бонус вампиризма вампиру, и чтоб каждая атака накладывала дебафф". Сложность геймдизайна в том, чтобы узнать, что из фантазий реально работает на пользу, а что лишь отвлекает от главной задачи и игрока, и разраба.
Конечно же, сделав гибкую систему навыков ты в будущем сможешь налепить любые навыки. Но тут ключевое слово "будущее", что может никогда и не наступить для твоей идеи игры... А вдруг ты потом обнаружишь, что всё фигня и достаточно лупить единственной оптимальной атакой? Потраченное на бесполезную разработку время уже не вернуть.
Короче, если ты ещё не сделал рабочий прототип, сфокусируйся на минимальном геймплее вроде:
- 1 герой со статичной аватаркой-затычкой;
- 2-3 типа врага со статичным спрайтом;
- 2-3 типа атаки, 2-3 типа дебаффа;
- 2-3 локации для навигации;
- конечная цель геймплея;
- базовые менюшечки.
Потом уже будешь ломать голову над тем, как это расширять и чем расширять интереснее всего. Даже минимальный геймплей луп задолбаешься делать...
Просто говорю по опыту, как тот, кто постоянно себе выдумывал какие-то расширяемые велосипеды, но в результате никак их ни к чему не применил и бросил. Потому что игра важнее каких-то мудрёных систем.
>>34441
Это хорошо только для уникальных нод...
Не забывай, что у нод есть своя цена.
>>34444
Ты хочешь ради этого менять структуру/состояние компонентов всех навыков персонажа, верно? Это выглядит неэффективно... Я бы добавил концепцию модификатора урона: навыки сами по себе никак не меняются, но к ним применяются доп. действия.
Тогда получается что-то вроде:
1. Навык генерирует урон по цели.
2. Урон передаётся вверх к владельцу.
3. Владелец добавляет к нему бонус расы.
4. Владелец отправляет урон назначенной цели.
Имхо, это лучше, чем как-то менять все навыки... Независимо от того, можно ли менять навыки.
Слот в GUI ≠ слот в программной структуре объекта. Пассивные эффекты могут быть в другом месте...
Речь шла о том, чтоб сделать ПРОТОТИП.
Вот ты сейчас можешь поиграть в свою игру? На компьютере, а не в своих фантазиях. Потому что на данный момент твоё описание выглядит как чистая фантазия "было бы круто давать бонус вампиризма вампиру, и чтоб каждая атака накладывала дебафф". Сложность геймдизайна в том, чтобы узнать, что из фантазий реально работает на пользу, а что лишь отвлекает от главной задачи и игрока, и разраба.
Конечно же, сделав гибкую систему навыков ты в будущем сможешь налепить любые навыки. Но тут ключевое слово "будущее", что может никогда и не наступить для твоей идеи игры... А вдруг ты потом обнаружишь, что всё фигня и достаточно лупить единственной оптимальной атакой? Потраченное на бесполезную разработку время уже не вернуть.
Короче, если ты ещё не сделал рабочий прототип, сфокусируйся на минимальном геймплее вроде:
- 1 герой со статичной аватаркой-затычкой;
- 2-3 типа врага со статичным спрайтом;
- 2-3 типа атаки, 2-3 типа дебаффа;
- 2-3 локации для навигации;
- конечная цель геймплея;
- базовые менюшечки.
Потом уже будешь ломать голову над тем, как это расширять и чем расширять интереснее всего. Даже минимальный геймплей луп задолбаешься делать...
Просто говорю по опыту, как тот, кто постоянно себе выдумывал какие-то расширяемые велосипеды, но в результате никак их ни к чему не применил и бросил. Потому что игра важнее каких-то мудрёных систем.
>наследуешь от белой ноды
Это хорошо только для уникальных нод...
Не забывай, что у нод есть своя цена.
>>34444
>допустим, после каждого нанесения урона должен накладываться дебафф, все прямые нанесения урона наносят урон 2 раза по половине от начального, а любое лечение сверх максимального хп спавнит дополнительного союзника
Ты хочешь ради этого менять структуру/состояние компонентов всех навыков персонажа, верно? Это выглядит неэффективно... Я бы добавил концепцию модификатора урона: навыки сами по себе никак не меняются, но к ним применяются доп. действия.
Тогда получается что-то вроде:
1. Навык генерирует урон по цели.
2. Урон передаётся вверх к владельцу.
3. Владелец добавляет к нему бонус расы.
4. Владелец отправляет урон назначенной цели.
Имхо, это лучше, чем как-то менять все навыки... Независимо от того, можно ли менять навыки.
>слот навыка может заменять пассивка
Слот в GUI ≠ слот в программной структуре объекта. Пассивные эффекты могут быть в другом месте...
>сложнее делать какие-то модификации
Речь шла о том, чтоб сделать ПРОТОТИП.
Вот ты сейчас можешь поиграть в свою игру? На компьютере, а не в своих фантазиях. Потому что на данный момент твоё описание выглядит как чистая фантазия "было бы круто давать бонус вампиризма вампиру, и чтоб каждая атака накладывала дебафф". Сложность геймдизайна в том, чтобы узнать, что из фантазий реально работает на пользу, а что лишь отвлекает от главной задачи и игрока, и разраба.
Конечно же, сделав гибкую систему навыков ты в будущем сможешь налепить любые навыки. Но тут ключевое слово "будущее", что может никогда и не наступить для твоей идеи игры... А вдруг ты потом обнаружишь, что всё фигня и достаточно лупить единственной оптимальной атакой? Потраченное на бесполезную разработку время уже не вернуть.
Короче, если ты ещё не сделал рабочий прототип, сфокусируйся на минимальном геймплее вроде:
- 1 герой со статичной аватаркой-затычкой;
- 2-3 типа врага со статичным спрайтом;
- 2-3 типа атаки, 2-3 типа дебаффа;
- 2-3 локации для навигации;
- конечная цель геймплея;
- базовые менюшечки.
Потом уже будешь ломать голову над тем, как это расширять и чем расширять интереснее всего. Даже минимальный геймплей луп задолбаешься делать...
Просто говорю по опыту, как тот, кто постоянно себе выдумывал какие-то расширяемые велосипеды, но в результате никак их ни к чему не применил и бросил. Потому что игра важнее каких-то мудрёных систем.
>>34565
Официально рекомендуют группировать вокруг сцен:
https://docs.godotengine.org/en/stable/tutorials/best_practices/project_organization.html
Под "ассетами" понимаются и скрипты тоже.
Видео пишут на скорую руку и в основном люди без реального опыта разработки. Как накидали - так и показывают. Поэтому всё в одно место свалено.
Я делаю примерно так:
И так далее.
Привыкай. Файл .tscn - это тоже код, только он не императивный, а декларативный (по типу HTML) - описывает, как сцена должна будет выглядеть. Ещё возможно сохранить GDScript прямо в .tscn, если это небольшой связывающий кусочек кода (там есть ограничения, но зачастую это не страшно).
В принципе, практически всё можно запаковать в единственный файл .tscn, но это будет неудобно и неэффективно (чем толще файл, тем сильнее лаги редактора при открытии, сохранении и т.д.). Но это полезно знать, т.к. иногда Godot пытается сохранить ресурсы неэффективно (особенно мешей касается - почему-то они у меня часто в .tscn залезают).
Алсо, чаще всего в Godot ты оперируешь сценами: загружаешь, вставляешь в дерево, удаляешь или заменяешь. Скрипты - это "расширение поведения" конкретных нод, из которых состоят сцены. Поэтому большинство скриптов принадлежит конкретным сохранённым в .tscn сценам, а не просто так. Но, разумеется, можно писать и скрипты-утилиты без конкретной связанной с ними сцены, если нужно.
Одно из преимуществ организации по папкам - в относительных путях. Вместо такого кода:
Код в файле player_model.gd может использовать:
Этот путь будет работать даже при переносе папки.
Если пишешь код не на GDScript, то смотри сам. Как правило другие языки используют ради скорости выполнения, а она нужна только для определённых числодробительных систем. Такие системы лучше отделить от сцен в виде скриптов-утилит, ИМХО.
Собственно, основная задача GDScript - быть "клеем", связующим компоненты игры в единую систему. Это означает, что логичное место - вместе с контентом.
Официально рекомендуют группировать вокруг сцен:
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 - быть "клеем", связующим компоненты игры в единую систему. Это означает, что логичное место - вместе с контентом.
>>34565
Официально рекомендуют группировать вокруг сцен:
https://docs.godotengine.org/en/stable/tutorials/best_practices/project_organization.html
Под "ассетами" понимаются и скрипты тоже.
Видео пишут на скорую руку и в основном люди без реального опыта разработки. Как накидали - так и показывают. Поэтому всё в одно место свалено.
Я делаю примерно так:
И так далее.
Привыкай. Файл .tscn - это тоже код, только он не императивный, а декларативный (по типу HTML) - описывает, как сцена должна будет выглядеть. Ещё возможно сохранить GDScript прямо в .tscn, если это небольшой связывающий кусочек кода (там есть ограничения, но зачастую это не страшно).
В принципе, практически всё можно запаковать в единственный файл .tscn, но это будет неудобно и неэффективно (чем толще файл, тем сильнее лаги редактора при открытии, сохранении и т.д.). Но это полезно знать, т.к. иногда Godot пытается сохранить ресурсы неэффективно (особенно мешей касается - почему-то они у меня часто в .tscn залезают).
Алсо, чаще всего в Godot ты оперируешь сценами: загружаешь, вставляешь в дерево, удаляешь или заменяешь. Скрипты - это "расширение поведения" конкретных нод, из которых состоят сцены. Поэтому большинство скриптов принадлежит конкретным сохранённым в .tscn сценам, а не просто так. Но, разумеется, можно писать и скрипты-утилиты без конкретной связанной с ними сцены, если нужно.
Одно из преимуществ организации по папкам - в относительных путях. Вместо такого кода:
Код в файле player_model.gd может использовать:
Этот путь будет работать даже при переносе папки.
Если пишешь код не на GDScript, то смотри сам. Как правило другие языки используют ради скорости выполнения, а она нужна только для определённых числодробительных систем. Такие системы лучше отделить от сцен в виде скриптов-утилит, ИМХО.
Собственно, основная задача GDScript - быть "клеем", связующим компоненты игры в единую систему. Это означает, что логичное место - вместе с контентом.
Официально рекомендуют группировать вокруг сцен:
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 - быть "клеем", связующим компоненты игры в единую систему. Это означает, что логичное место - вместе с контентом.
>>34604
Я сейчас прочёл твой пост и придумал идею аддона для редактора. Аддон который при его активации над открытой сценой проверяет все ресурсы и предлагает сохранить отдельно все найденные вложенные. Либо автоматически сохраняет без вопросов, если настроить в конфиге политику именования.
Я сейчас прочёл твой пост и придумал идею аддона для редактора. Аддон который при его активации над открытой сценой проверяет все ресурсы и предлагает сохранить отдельно все найденные вложенные. Либо автоматически сохраняет без вопросов, если настроить в конфиге политику именования.
>>34604
Ладно, буду экспериментировать. То, что сцена тоже код, уже задумывался в качестве психологического компромиса, да и ковыряться в них ручками уже приходилось, спасибо глюкам. Так же задумывался, что редактор в случае переноса туда сюда удобнее будет использоваться, так как реструктурировать нужно лишь общюю директорюю payer например, а не scenes/player, src/player, resources/player отдельно например. Но это мелочи на моих хеловорд хуевинах. Как раз хотел понять как делают люди с большими достаточно проектами.
Ладно, буду экспериментировать. То, что сцена тоже код, уже задумывался в качестве психологического компромиса, да и ковыряться в них ручками уже приходилось, спасибо глюкам. Так же задумывался, что редактор в случае переноса туда сюда удобнее будет использоваться, так как реструктурировать нужно лишь общюю директорюю payer например, а не scenes/player, src/player, resources/player отдельно например. Но это мелочи на моих хеловорд хуевинах. Как раз хотел понять как делают люди с большими достаточно проектами.
>>34604
дык это база, основа в подобных движках. в итоге получается почти небинарное дерево aka SceneTree
>рекомендуют группировать вокруг сцен
дык это база, основа в подобных движках. в итоге получается почти небинарное дерево aka SceneTree
>>34585
Всех активных навыков в данный момент (неактивных может быть больше, как колода карт и рука), при условии, что навыков всего будет максимум 5, не думаю, что это слишком переусложняет задачу
Да, я это написал к тому, что навыков мало, и может быть ещё меньше, это как в нойте при лимите в 4 палки вешать на одну одновременно и копание, и телепорт, и лечение
Мне кажется, такое распыление плохо влияет на возможность модификации, даже чем-то простым, например:
- целевая атака становится случайной
- целевая атака становится атакой по всем врагам
- у атаки есть собственный дебафф, который складывается с доп. дебаффами сверху
- модификатор, от которого провоцируется активация навыка союзника
Если это всё добавлять сигналами или маркерами и передавать выше, придётся добавлять эти маркеры во все навыки, что превратится в жуткую мешанину, вроде как добавить ноду ещё одного действия или заменить одно действие на другое, выглядит не так сложно
Частично, сделаны герой, враг, система ходов, очки действия, "рука" навыков, и я как раз сделал навыки кодом и появилась проблема как с этим адекватно работать, если навык начнёт делать что-то большее, чем просто наносить урон одной цели, пусть даже просто начнёт наносить урон случайной цели, каждый раз вынимать навык из колоды и менять на другой выглядит неэффективно, тем более что придётся выдумывать, как эти навыки делить на подкатегории (наверное, проблема с этих "подкатегорий" и началась, лучше сделать категории на "действия", но не на "навыки", как контейнер "действий")
> Ты хочешь ради этого менять структуру/состояние компонентов всех навыков персонажа, верно?
Всех активных навыков в данный момент (неактивных может быть больше, как колода карт и рука), при условии, что навыков всего будет максимум 5, не думаю, что это слишком переусложняет задачу
>> слот навыка может заменять пассивка
> Слот в GUI ≠ слот в программной структуре объекта
Да, я это написал к тому, что навыков мало, и может быть ещё меньше, это как в нойте при лимите в 4 палки вешать на одну одновременно и копание, и телепорт, и лечение
> 1. Навык генерирует урон по цели.
> 2. Урон передаётся вверх к владельцу.
> 3. Владелец добавляет к нему бонус расы.
> 4. Владелец отправляет урон назначенной цели.
Мне кажется, такое распыление плохо влияет на возможность модификации, даже чем-то простым, например:
- целевая атака становится случайной
- целевая атака становится атакой по всем врагам
- у атаки есть собственный дебафф, который складывается с доп. дебаффами сверху
- модификатор, от которого провоцируется активация навыка союзника
Если это всё добавлять сигналами или маркерами и передавать выше, придётся добавлять эти маркеры во все навыки, что превратится в жуткую мешанину, вроде как добавить ноду ещё одного действия или заменить одно действие на другое, выглядит не так сложно
> Вот ты сейчас можешь поиграть в свою игру?
Частично, сделаны герой, враг, система ходов, очки действия, "рука" навыков, и я как раз сделал навыки кодом и появилась проблема как с этим адекватно работать, если навык начнёт делать что-то большее, чем просто наносить урон одной цели, пусть даже просто начнёт наносить урон случайной цели, каждый раз вынимать навык из колоды и менять на другой выглядит неэффективно, тем более что придётся выдумывать, как эти навыки делить на подкатегории (наверное, проблема с этих "подкатегорий" и началась, лучше сделать категории на "действия", но не на "навыки", как контейнер "действий")
>>34565
Я храню в отдельном каталоге scripts, потому что один скрипт может подключаться к разным сценам, наследоваться, быть классом, быть СИНГЛТОНОМ без сцены и так далее.
Я храню в отдельном каталоге scripts, потому что один скрипт может подключаться к разным сценам, наследоваться, быть классом, быть СИНГЛТОНОМ без сцены и так далее.
>>34565
Пытался разделять несколько лет назад, в результате забил, уже лет 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/ на самом деле еще десяток модулей которые не аддоны. Например контроллер персонажа, хелсбары, миникарта, компас, стриминг уровня, таргетинг/обводка целей, тачскрин джойтик, вертексная анимация, декали и тд
Пытался разделять несколько лет назад, в результате забил, уже лет 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/ на самом деле еще десяток модулей которые не аддоны. Например контроллер персонажа, хелсбары, миникарта, компас, стриминг уровня, таргетинг/обводка целей, тачскрин джойтик, вертексная анимация, декали и тд
>>34639
Тоже прикольно. Я велосипедист, думал мне аддоны могут пригодиться как часть системы. Разве что я пока в обучении до них не дошел и не выкупаю особо чем аддон отличается от любой другой папочки которую просто ctrlc ctrlv.
Тоже прикольно. Я велосипедист, думал мне аддоны могут пригодиться как часть системы. Разве что я пока в обучении до них не дошел и не выкупаю особо чем аддон отличается от любой другой папочки которую просто ctrlc ctrlv.
>>34642
Зачастую (но не всегда) аддон содержит plugin.cfg в котором указан какой то тулскрипт, работающий внутри редактора.
Зачастую (но не всегда) аддон содержит plugin.cfg в котором указан какой то тулскрипт, работающий внутри редактора.
38 Кб, 720x585https://forum.godotengine.org/t/android-programming-for-performance-dos-and-donts/19212/3
1) Почему никто не сказал, когда спрашивал ИТТ?
2) Почему это до сих пор (Godot 4.3+) проблема?
3) Как делать красивый шрифт с анимацией?
>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) Как делать красивый шрифт с анимацией?
>>34614
Было бы идеально иметь способ просканировать все имеющиеся сцены на наличие в них base64 картинок, записанных в Array мешей и прочей фигни, которую по хорошему лучше хранить в бинарных файлах. Все эти текстовые форматы хороши только когда их можно вручную просмотреть, а не 20 Мб магических чисел.
Я знаю, что есть бинарный формат .scn, но в случае странностей и ошибок его можно только из архива восстановить. Текстовые tscn всё же полезны...
>>34617
А ещё удобнее переносить в новый проект. Если потребуется игра с чем-то, что уже было в старой - достаточно перенести одну папку, а не копаться в нескольких местах типа "ассеты/сцены/скрипты".
>>34622
У бинарного только две ветки - левая и правая. Есть просто "дерево" - структура данных с произвольным количеством веток. Как вложенные Array/Dictionary.
>идею аддона для редактора
Было бы идеально иметь способ просканировать все имеющиеся сцены на наличие в них base64 картинок, записанных в Array мешей и прочей фигни, которую по хорошему лучше хранить в бинарных файлах. Все эти текстовые форматы хороши только когда их можно вручную просмотреть, а не 20 Мб магических чисел.
Я знаю, что есть бинарный формат .scn, но в случае странностей и ошибок его можно только из архива восстановить. Текстовые tscn всё же полезны...
>>34617
>реструктурировать
А ещё удобнее переносить в новый проект. Если потребуется игра с чем-то, что уже было в старой - достаточно перенести одну папку, а не копаться в нескольких местах типа "ассеты/сцены/скрипты".
>>34622
>бинарное дерево aka SceneTree
У бинарного только две ветки - левая и правая. Есть просто "дерево" - структура данных с произвольным количеством веток. Как вложенные Array/Dictionary.
>>34661
Потому что конечно же каждый ИТТ твинит шрифты с аутлайном на старых андроидах. Каждый день этим занимаемся перед завтраком.
Я каждый раз, когда тут заходит диалог про разработку под могилки, говорю что могилки это лотерея. Там огромный зоопарк чипсетов и их версий, любой из которых запросто может не уметь любую банальную хуйню, даже на новых телефонах бюджетного сегмента. У меня одно время были отзывы в гуглплее вида "помогите, черный экран!!1", а я хуй знает почему, а потом оказалось что там какой-то нищий китайский чип не мог загрузить текстуру выше 512х512. В чипе в принципе отсутствует такой функционал.
А шрифты конкретно у меня твинятся на андроидах нормально. И на тех девайсах что я имею и в гугловском файербейсе с его кучей тестовых мобилок.
Потому что конечно же каждый ИТТ твинит шрифты с аутлайном на старых андроидах. Каждый день этим занимаемся перед завтраком.
Я каждый раз, когда тут заходит диалог про разработку под могилки, говорю что могилки это лотерея. Там огромный зоопарк чипсетов и их версий, любой из которых запросто может не уметь любую банальную хуйню, даже на новых телефонах бюджетного сегмента. У меня одно время были отзывы в гуглплее вида "помогите, черный экран!!1", а я хуй знает почему, а потом оказалось что там какой-то нищий китайский чип не мог загрузить текстуру выше 512х512. В чипе в принципе отсутствует такой функционал.
А шрифты конкретно у меня твинятся на андроидах нормально. И на тех девайсах что я имею и в гугловском файербейсе с его кучей тестовых мобилок.
>>34627
Есть понятие "преждевременная оптимизация", когда пытаются выжать миллисекунды почём зря, ухудшая читабельность и поддерживаемость кода. А есть... Не помню термин... Скажем, "чрезмерное планирование": пытаешься предусмотреть любые будущие варианты развития проекта и адаптироваться к ним заранее. Подобное планирование только замедляет работу.
Вот есть ECS, он типа "идеален" для игр, якобы даёт возможность "комбинировать всё со всем", но это аналогично языкам с динамической типизацией: запихнуть String можно куда угодно, но во многих ситуациях это приведёт к ошибкам или проблемам. Строгая типизация - это страховочная система, чтоб засовывать что надо и куда надо, а не куда попало. Классовая система объектов - тоже страховка от незапланированных смешиваний в системе, т.к. все данные и код делятся на конкретные группы/типы.
Хочу сказать, что "сложность незапланированной модификации в будущем" - не всегда недостаток системы. Твой код должен быть понятным, чтобы снизилась сложность модификации. Но если ты буквально что угодно с чем угодно соединяешь, понятность взаимодействия частей кода снизится.
Вот интересная статья на эту тему:
https://habr.com/ru/articles/568216/
Нужно избегать "destructive decoupling".
В общем. Какая-то гибкость нужна, типа менеджера навыков. Но избыточная "гибкость" превращается в непонятную кашу непонятно чего. Как спагетти-код. Спагетти можно распутать, пройдя по ссылкам, а деструктивная развязка переносит "спагетти" во взаимодействие в рантайме, что ещё сложнее...
Проблема может возникнуть из-за смены состояния объекта несколько раз. Скажем, был урон 100, далее:
- мод 1 уменьшает на 90%
- мод 2 добавляет 50 очков
- мод 3 умножает на 2
Выходит урон в 120. Но если поменять порядок, то получается уже 30 или 25. Так какой порядок считать правильным? И как игрок поймёт, в каком порядке складываются модификации на его оружии/навыке? Нужно убедиться, что порядок следует формуле, а не зависит от какого-то случайного фактора.
Я сначала неправильно выразился. Проблема не в технической "эффективности", наоборот, поменять множители один раз эффективнее по скорости и по расходу памяти. Но порядок действий может быть неправильным и отследить это будет тяжело.
Ладно. Я тоже чрезмерно всё планирую...
>возможность модификации
>если навык начнёт делать что-то большее
Есть понятие "преждевременная оптимизация", когда пытаются выжать миллисекунды почём зря, ухудшая читабельность и поддерживаемость кода. А есть... Не помню термин... Скажем, "чрезмерное планирование": пытаешься предусмотреть любые будущие варианты развития проекта и адаптироваться к ним заранее. Подобное планирование только замедляет работу.
Вот есть ECS, он типа "идеален" для игр, якобы даёт возможность "комбинировать всё со всем", но это аналогично языкам с динамической типизацией: запихнуть String можно куда угодно, но во многих ситуациях это приведёт к ошибкам или проблемам. Строгая типизация - это страховочная система, чтоб засовывать что надо и куда надо, а не куда попало. Классовая система объектов - тоже страховка от незапланированных смешиваний в системе, т.к. все данные и код делятся на конкретные группы/типы.
Хочу сказать, что "сложность незапланированной модификации в будущем" - не всегда недостаток системы. Твой код должен быть понятным, чтобы снизилась сложность модификации. Но если ты буквально что угодно с чем угодно соединяешь, понятность взаимодействия частей кода снизится.
Вот интересная статья на эту тему:
https://habr.com/ru/articles/568216/
Нужно избегать "destructive decoupling".
В общем. Какая-то гибкость нужна, типа менеджера навыков. Но избыточная "гибкость" превращается в непонятную кашу непонятно чего. Как спагетти-код. Спагетти можно распутать, пройдя по ссылкам, а деструктивная развязка переносит "спагетти" во взаимодействие в рантайме, что ещё сложнее...
>навыков всего будет максимум 5
Проблема может возникнуть из-за смены состояния объекта несколько раз. Скажем, был урон 100, далее:
- мод 1 уменьшает на 90%
- мод 2 добавляет 50 очков
- мод 3 умножает на 2
Выходит урон в 120. Но если поменять порядок, то получается уже 30 или 25. Так какой порядок считать правильным? И как игрок поймёт, в каком порядке складываются модификации на его оружии/навыке? Нужно убедиться, что порядок следует формуле, а не зависит от какого-то случайного фактора.
Я сначала неправильно выразился. Проблема не в технической "эффективности", наоборот, поменять множители один раз эффективнее по скорости и по расходу памяти. Но порядок действий может быть неправильным и отследить это будет тяжело.
Ладно. Я тоже чрезмерно всё планирую...
>>34627
Есть понятие "преждевременная оптимизация", когда пытаются выжать миллисекунды почём зря, ухудшая читабельность и поддерживаемость кода. А есть... Не помню термин... Скажем, "чрезмерное планирование": пытаешься предусмотреть любые будущие варианты развития проекта и адаптироваться к ним заранее. Подобное планирование только замедляет работу.
Вот есть ECS, он типа "идеален" для игр, якобы даёт возможность "комбинировать всё со всем", но это аналогично языкам с динамической типизацией: запихнуть String можно куда угодно, но во многих ситуациях это приведёт к ошибкам или проблемам. Строгая типизация - это страховочная система, чтоб засовывать что надо и куда надо, а не куда попало. Классовая система объектов - тоже страховка от незапланированных смешиваний в системе, т.к. все данные и код делятся на конкретные группы/типы.
Хочу сказать, что "сложность незапланированной модификации в будущем" - не всегда недостаток системы. Твой код должен быть понятным, чтобы снизилась сложность модификации. Но если ты буквально что угодно с чем угодно соединяешь, понятность взаимодействия частей кода снизится.
Вот интересная статья на эту тему:
https://habr.com/ru/articles/568216/
Нужно избегать "destructive decoupling".
В общем. Какая-то гибкость нужна, типа менеджера навыков. Но избыточная "гибкость" превращается в непонятную кашу непонятно чего. Как спагетти-код. Спагетти можно распутать, пройдя по ссылкам, а деструктивная развязка переносит "спагетти" во взаимодействие в рантайме, что ещё сложнее...
Проблема может возникнуть из-за смены состояния объекта несколько раз. Скажем, был урон 100, далее:
- мод 1 уменьшает на 90%
- мод 2 добавляет 50 очков
- мод 3 умножает на 2
Выходит урон в 120. Но если поменять порядок, то получается уже 30 или 25. Так какой порядок считать правильным? И как игрок поймёт, в каком порядке складываются модификации на его оружии/навыке? Нужно убедиться, что порядок следует формуле, а не зависит от какого-то случайного фактора.
Я сначала неправильно выразился. Проблема не в технической "эффективности", наоборот, поменять множители один раз эффективнее по скорости и по расходу памяти. Но порядок действий может быть неправильным и отследить это будет тяжело.
Ладно. Я тоже чрезмерно всё планирую...
>возможность модификации
>если навык начнёт делать что-то большее
Есть понятие "преждевременная оптимизация", когда пытаются выжать миллисекунды почём зря, ухудшая читабельность и поддерживаемость кода. А есть... Не помню термин... Скажем, "чрезмерное планирование": пытаешься предусмотреть любые будущие варианты развития проекта и адаптироваться к ним заранее. Подобное планирование только замедляет работу.
Вот есть ECS, он типа "идеален" для игр, якобы даёт возможность "комбинировать всё со всем", но это аналогично языкам с динамической типизацией: запихнуть String можно куда угодно, но во многих ситуациях это приведёт к ошибкам или проблемам. Строгая типизация - это страховочная система, чтоб засовывать что надо и куда надо, а не куда попало. Классовая система объектов - тоже страховка от незапланированных смешиваний в системе, т.к. все данные и код делятся на конкретные группы/типы.
Хочу сказать, что "сложность незапланированной модификации в будущем" - не всегда недостаток системы. Твой код должен быть понятным, чтобы снизилась сложность модификации. Но если ты буквально что угодно с чем угодно соединяешь, понятность взаимодействия частей кода снизится.
Вот интересная статья на эту тему:
https://habr.com/ru/articles/568216/
Нужно избегать "destructive decoupling".
В общем. Какая-то гибкость нужна, типа менеджера навыков. Но избыточная "гибкость" превращается в непонятную кашу непонятно чего. Как спагетти-код. Спагетти можно распутать, пройдя по ссылкам, а деструктивная развязка переносит "спагетти" во взаимодействие в рантайме, что ещё сложнее...
>навыков всего будет максимум 5
Проблема может возникнуть из-за смены состояния объекта несколько раз. Скажем, был урон 100, далее:
- мод 1 уменьшает на 90%
- мод 2 добавляет 50 очков
- мод 3 умножает на 2
Выходит урон в 120. Но если поменять порядок, то получается уже 30 или 25. Так какой порядок считать правильным? И как игрок поймёт, в каком порядке складываются модификации на его оружии/навыке? Нужно убедиться, что порядок следует формуле, а не зависит от какого-то случайного фактора.
Я сначала неправильно выразился. Проблема не в технической "эффективности", наоборот, поменять множители один раз эффективнее по скорости и по расходу памяти. Но порядок действий может быть неправильным и отследить это будет тяжело.
Ладно. Я тоже чрезмерно всё планирую...
>>34661
Писали неоднократно. Шрифт работает так практически везде, он собирает команды на рисование вектора и всяких хинтингов и кеширует нарисованый атлас. При изменении размера шрифта все перегенеривается. Про аутлайн не в курсе.
Попробуй галочку SDF шрифт. Хотя может на мобилке это медленнее.
Можно попробовать аутлайн шейдер. Он же будет искать закрашенные пиксели и расширять зону.
Если вопрос в аутлайне, можно сделать псевдаутлайн, вывести на фоне текст еще раз и скейлить его через scale, а не менять размер.
Можно еще что то придумать. Отрендерить нужные размеры текстов и анимировать как флипбук
> Почему никто не сказал
Писали неоднократно. Шрифт работает так практически везде, он собирает команды на рисование вектора и всяких хинтингов и кеширует нарисованый атлас. При изменении размера шрифта все перегенеривается. Про аутлайн не в курсе.
>Что делать
Попробуй галочку SDF шрифт. Хотя может на мобилке это медленнее.
Можно попробовать аутлайн шейдер. Он же будет искать закрашенные пиксели и расширять зону.
Если вопрос в аутлайне, можно сделать псевдаутлайн, вывести на фоне текст еще раз и скейлить его через scale, а не менять размер.
Можно еще что то придумать. Отрендерить нужные размеры текстов и анимировать как флипбук
>>34681
Мне вот сложно нащупать эту середину. С одной стороны мне хочется убивать, когда я вижу на похуй накиданный код. Типа да, он простой и даже понятный, но то что он не бажит вот прям здесь и сейчас, запускает и не рушится это пиздец какая удача в 99% случаев, а если расширять нужно ctrl+a - delete сразу делать. С другой слишком гибко и четко и даже без багов - это для точно такой же херни, что решает первый кусок говна придется потратить х100 времени. Зато будет непробиваемо и идеально расширяемо, правда никому не нужно, кроме моего перфекционизма. В целом таким страдаю в макакерстве своем, не только в гд. В игре одной захуярил скриптовый язык транзакционный, полностью безопасный, чтобы контентные негры могли сами скрипты писать к квестам/диалогам и тд. Итог - нихуя они не писали, хотя язык был намеренно проще некуда специально под эту задачу. Не пригодился, заставили меня самого все делать. Вот такой вот я планировщик ебанат.
Мне вот сложно нащупать эту середину. С одной стороны мне хочется убивать, когда я вижу на похуй накиданный код. Типа да, он простой и даже понятный, но то что он не бажит вот прям здесь и сейчас, запускает и не рушится это пиздец какая удача в 99% случаев, а если расширять нужно ctrl+a - delete сразу делать. С другой слишком гибко и четко и даже без багов - это для точно такой же херни, что решает первый кусок говна придется потратить х100 времени. Зато будет непробиваемо и идеально расширяемо, правда никому не нужно, кроме моего перфекционизма. В целом таким страдаю в макакерстве своем, не только в гд. В игре одной захуярил скриптовый язык транзакционный, полностью безопасный, чтобы контентные негры могли сами скрипты писать к квестам/диалогам и тд. Итог - нихуя они не писали, хотя язык был намеренно проще некуда специально под эту задачу. Не пригодился, заставили меня самого все делать. Вот такой вот я планировщик ебанат.
>>34669
Пошутил так пошутил, я аж улыбнулся))) Шрифты с обводочкой - база, твин гуя - база, старый андроид - работает и не жалуется... Или ты только статичные пиксельные шрифты на новые флагманы делаешь?
>>34682
Размер шрифта в Label (или RichTextLabel) точно не менялся. Менялся только PanelContainer в предках. Неужели это вызывает рендеринг шрифта заново?
Короч, идея была такой: квадратное окошко быстро анимируется в стороны и на нём печатается текст... Сначала вроде норм было, а потом залагало всё.
Да наверняка будет ухудшать рендеринг... Пожалуй, нужно проверить, не включил ли я его случайно. Т.к. перетаскивал шрифт из одного проекта в другой...
Возможно, это просто шрифт такой жирный... Очень сложно найти красивый, открытый шрифт с полной поддержкой кириллицы и хорошей читаемостью.
Да это понятно. Просто проект уровня hello world, ВНЕЗАПНО вызывающий лаги шторки Android из-за нагрузки на GPU, как-то не очень вдохновляет. Если говорить прямо, я разочаровался и впал в депру...
Попробую что-нибудь сделать, авось получится.
Телефон среднего уровня, но осени 2019...
>Потому что конечно же каждый ИТТ твинит шрифты с аутлайном на старых андроидах. Каждый день этим занимаемся перед завтраком.
Пошутил так пошутил, я аж улыбнулся))) Шрифты с обводочкой - база, твин гуя - база, старый андроид - работает и не жалуется... Или ты только статичные пиксельные шрифты на новые флагманы делаешь?
>>34682
>При изменении размера шрифта
Размер шрифта в Label (или RichTextLabel) точно не менялся. Менялся только PanelContainer в предках. Неужели это вызывает рендеринг шрифта заново?
Короч, идея была такой: квадратное окошко быстро анимируется в стороны и на нём печатается текст... Сначала вроде норм было, а потом залагало всё.
>Попробуй галочку SDF шрифт.
Да наверняка будет ухудшать рендеринг... Пожалуй, нужно проверить, не включил ли я его случайно. Т.к. перетаскивал шрифт из одного проекта в другой...
Возможно, это просто шрифт такой жирный... Очень сложно найти красивый, открытый шрифт с полной поддержкой кириллицы и хорошей читаемостью.
>Можно еще что то придумать
Да это понятно. Просто проект уровня hello world, ВНЕЗАПНО вызывающий лаги шторки Android из-за нагрузки на GPU, как-то не очень вдохновляет. Если говорить прямо, я разочаровался и впал в депру...
Попробую что-нибудь сделать, авось получится.
Телефон среднего уровня, но осени 2019...
>>34690
Таких тонкостей не припомню, что панель контейнер меняет, разве не просто scale? что именно ты твинишь то? Попробуй без контейнера.
а еще я бы для мобилки делал на 3.6
Таких тонкостей не припомню, что панель контейнер меняет, разве не просто scale? что именно ты твинишь то? Попробуй без контейнера.
а еще я бы для мобилки делал на 3.6
>>34585
У белых нод (Node) минимальная цена, неотличимая от того же ресурса.
> Не забывай, что у нод есть своя цена.
У белых нод (Node) минимальная цена, неотличимая от того же ресурса.
Кто-то из вас делал приложения на годоте? Если да, то как оно?
да, я знаю, что они существуют, но мне интересно мнение живого человека, а не просто знать о наличие такого софта
да, я знаю, что они существуют, но мне интересно мнение живого человека, а не просто знать о наличие такого софта
>>34728
Делал морду для чатгпт, это подойдет? Заюзал изза легчайшего гуя только, логика питонячьим сервисом.
Делал морду для чатгпт, это подойдет? Заюзал изза легчайшего гуя только, логика питонячьим сервисом.
>>34741
У меня нет. Годот и взял потому что гуи в большинстве случаев просто ужасающее говно на других языках. Годнота еще электрон в плане разработки и внешки, но как же мерзотно он лагает мамамия. Так что взял и не жалею. Даже прикольное ощущение, что пока ты пилишь гуй твой инструмент по сути может предложить мощ целого игрового движка в любой момент при желании, а не только кнопочки с дизайном из виндоус95, как какойнибудь ткинтер.
У меня нет. Годот и взял потому что гуи в большинстве случаев просто ужасающее говно на других языках. Годнота еще электрон в плане разработки и внешки, но как же мерзотно он лагает мамамия. Так что взял и не жалею. Даже прикольное ощущение, что пока ты пилишь гуй твой инструмент по сути может предложить мощ целого игрового движка в любой момент при желании, а не только кнопочки с дизайном из виндоус95, как какойнибудь ткинтер.
42 Кб, 604x1003>>34728
делал пикрил лол, активно пользуюсь
записываешь название, прога сохраняет это с текущей датой как списочек в файл, при следующем открытии загружает этот файл, если 2 раза кликнуть на крестик удаляет запись и сохраняет изменения
первое поделие в годоте, я немного мобильную разработку на kotlin ковырял перед этим, в целом ни там, ни там не душно интерфейс делать, достаточно удобно, разве что в мобке надо ещё поворот экрана учитывать
делал пикрил лол, активно пользуюсь
записываешь название, прога сохраняет это с текущей датой как списочек в файл, при следующем открытии загружает этот файл, если 2 раза кликнуть на крестик удаляет запись и сохраняет изменения
первое поделие в годоте, я немного мобильную разработку на kotlin ковырял перед этим, в целом ни там, ни там не душно интерфейс делать, достаточно удобно, разве что в мобке надо ещё поворот экрана учитывать
>>34741
В целом было максимально комфортно. Нет, не возникало мысли дропнуть. На других языках делал, там куча своих проблем с графоном. Тут взял и работает.
В гуе не все можно сделать из коробки, ну так это игровой движок а не симулятор html. Что то там всем тредом не могли выставить, внешний марджин вокруг текста в кнопке вроде бы, и многопроходные шейдеры на те же кнопки. Но это объявляется нинужно и двигаешься дальше.
В целом было максимально комфортно. Нет, не возникало мысли дропнуть. На других языках делал, там куча своих проблем с графоном. Тут взял и работает.
В гуе не все можно сделать из коробки, ну так это игровой движок а не симулятор html. Что то там всем тредом не могли выставить, внешний марджин вокруг текста в кнопке вроде бы, и многопроходные шейдеры на те же кнопки. Но это объявляется нинужно и двигаешься дальше.
>>34746
Бонусом было что в приложении использовались 3д элементы. Витуберский аватар как пример похожего с захватом с камеры.
Бонусом было что в приложении использовались 3д элементы. Витуберский аватар как пример похожего с захватом с камеры.
>>34728
Делал гуевую программу для обучения школоты. Получилось быстро-просто, всегда бы так.
Делал гуевую программу для обучения школоты. Получилось быстро-просто, всегда бы так.
>>34742
Падажжи, но ведь МСКоде написан на электроне, и он вполне себе шустр. Может ты делал это неправильно?
> электрон в плане разработки и внешки, но как же мерзотно он лагает мамамия
Падажжи, но ведь МСКоде написан на электроне, и он вполне себе шустр. Может ты делал это неправильно?
>>34728
Я делал конструктор диалогов в стиле древнего движка "аврора" (невервинтер, первый ведьмак), планировался именно отдельный инструмент, а не аддон, но потом появился диалоджик, который обошёл меня во всём, я словил демотивацию и забросил. Но пока я эту приложуху делал, проблем не испытывал. Любой элемент управления легко конструируется композицией. У меня получались выпадающие списки с элементами вводимыми на лету в диалоговые поля и т.п. И всё это на трёшке. А сегодня в четвёрке с функциями первого порядка будет еще проще. Вплоть до реализации паттерна MVVM.
Я делал конструктор диалогов в стиле древнего движка "аврора" (невервинтер, первый ведьмак), планировался именно отдельный инструмент, а не аддон, но потом появился диалоджик, который обошёл меня во всём, я словил демотивацию и забросил. Но пока я эту приложуху делал, проблем не испытывал. Любой элемент управления легко конструируется композицией. У меня получались выпадающие списки с элементами вводимыми на лету в диалоговые поля и т.п. И всё это на трёшке. А сегодня в четвёрке с функциями первого порядка будет еще проще. Вплоть до реализации паттерна MVVM.
7 Кб, 316x94Короче нужно сделать "инвентарь" самый базовый. И хочу чтоб его можно было через @export редактировать. От туда будет просто браться число чтоб показать сколько у нас этих предметов. И вот я типа использую func change_item(id, value), где ид - это ид предмета, который будем менять, а валуе - это на сколько будем менять. И я типа такой: "эээ я просто сделаю массив переменных и буду оттуда вызывать гыгы", А В МАССИВЕ-ТО НЕ ССЫЛКИ НА ПЕРЕМЕННЫЕ, А ВООБЩЕ ДРУГИЕ ПЕРЕМЕННЫЕ. Когда я вызываю по ид предмет из массив, то я меняю его число только в массиве, а не не на самой @export переменной. Воооооооот...
А предметов-то будет, не больше десятка. Ну и короче оно адекватно будет через match менять переменные или это говняк?
А предметов-то будет, не больше десятка. Ну и короче оно адекватно будет через match менять переменные или это говняк?
Если кто еще тут левелдизайнит - используйте паттерны в своих декорациях. Кирпичи могут валяться не просто так, а паттерном, что сразу делает все красивее минимальными усилиями.
Кстати, какие фишки редактора помогают в 3д? Я например часто жму F - центрирует камеру на выбранном объекте. Альт + правый клик - показывает список объектов под кликом, полезно когда объекты навалены кучей.
Кстати, какие фишки редактора помогают в 3д? Я например часто жму F - центрирует камеру на выбранном объекте. Альт + правый клик - показывает список объектов под кликом, полезно когда объекты навалены кучей.
>>34828
Я делал это очень давно. И вскод в молодости лагал как десяток иде разом. До него еще кое кто был, не выжил. Сейчас да, уже не заметно почти, говорят когда оптимизируешь хуевину десяток лет неограниченными ресурсами такое мождет произойти.
Я делал это очень давно. И вскод в молодости лагал как десяток иде разом. До него еще кое кто был, не выжил. Сейчас да, уже не заметно почти, говорят когда оптимизируешь хуевину десяток лет неограниченными ресурсами такое мождет произойти.
>>34834
Че он несет? Просто экспортируй сам массив, зачем тебе отдельные переменные?
@export var inventory : Array[int] = [...]
И все, и больше ничего
func change_item(id, value):
____inventory[ID] += value
И больше ничего
>Когда я вызываю по ид предмет из массив, то я меняю его число только в массиве, а не не на самой @export переменной
Че он несет? Просто экспортируй сам массив, зачем тебе отдельные переменные?
@export var inventory : Array[int] = [...]
И все, и больше ничего
func change_item(id, value):
____inventory[ID] += value
И больше ничего
>>34834
Без сарказма и без троллинга инвентарь это
список. Просто список. А всё остальное (что ты хочешь на самом деле) это обёртки для работы с этим списком.
А теперь, зная это, подумай и напиши, что ты хочешь конкретно, именно.
> Короче нужно сделать "инвентарь" самый базовый.
Без сарказма и без троллинга инвентарь это
> var inventory := []
список. Просто список. А всё остальное (что ты хочешь на самом деле) это обёртки для работы с этим списком.
А теперь, зная это, подумай и напиши, что ты хочешь конкретно, именно.
>>34728
Пробовал делать несколько утилит, ничего серьёзного. Godot с GDScript удобен и всё такое, но очень тяжёлый. Раньше активно кодил в Delphi и Lazarus, до сих пор пользуюсь одной своей программой на Lazarus под Windows. Думал переделать её на Godot, но увидел:
- оперативной памяти Godot тратит раз в 10 больше;
- фоновая нагрузка на CPU выше даже с костылями;
- тратится видеопамять, плохо на фоне игр держать;
- сравнительно дольше перезапуск (2~3 секунды).
Так что мотивация как-то быстро улетучилась, лол.
В общем, Godot очень хорош для больших программ наподобие какого-нибудь Blender, где очень много UI, сложные операции и программа не держится на фоне круглосуточно в качестве мини-помощника/утилиты.
Для мелких утилит Godot равен Electron/Python/etc - прожирает ресурсы компа сильнее твоего кода, лол.
Собственно, ожидаемо. Этот ж ИГРОВОЙ движок.
Отдельно замечу, что прикладным программам по определению не нужен красивый GUI, поэтому выше описанная критика "окно как в Win95" некорректна. Прикладная программа - не игрушка, и ей главное выполнять работу точно и в срок, с минимальными затратами критических ресурсов. Красота GUI на последнем месте, лишь бы все кнопки работали. Наоборот, чем "красивее" GUI, тем хуже, ибо этот GUI растрачивает ресурсы, необходимые пользователю.
>приложения на годоте
Пробовал делать несколько утилит, ничего серьёзного. Godot с GDScript удобен и всё такое, но очень тяжёлый. Раньше активно кодил в Delphi и Lazarus, до сих пор пользуюсь одной своей программой на Lazarus под Windows. Думал переделать её на Godot, но увидел:
- оперативной памяти Godot тратит раз в 10 больше;
- фоновая нагрузка на CPU выше даже с костылями;
- тратится видеопамять, плохо на фоне игр держать;
- сравнительно дольше перезапуск (2~3 секунды).
Так что мотивация как-то быстро улетучилась, лол.
В общем, Godot очень хорош для больших программ наподобие какого-нибудь Blender, где очень много UI, сложные операции и программа не держится на фоне круглосуточно в качестве мини-помощника/утилиты.
Для мелких утилит Godot равен Electron/Python/etc - прожирает ресурсы компа сильнее твоего кода, лол.
Собственно, ожидаемо. Этот ж ИГРОВОЙ движок.
Отдельно замечу, что прикладным программам по определению не нужен красивый GUI, поэтому выше описанная критика "окно как в Win95" некорректна. Прикладная программа - не игрушка, и ей главное выполнять работу точно и в срок, с минимальными затратами критических ресурсов. Красота GUI на последнем месте, лишь бы все кнопки работали. Наоборот, чем "красивее" GUI, тем хуже, ибо этот GUI растрачивает ресурсы, необходимые пользователю.
>>34926
Расскажи свой последний абзац в desktop ricing тредах. Сам я по ним не угораю, но когда-то написал опенсорную консольную программку, и пару раз ее видел на скринах анонов на форче, реддите, и даже на дваче, лол. Причем я уверен что как программа она им была не нужна, просто выглядела прикольно.
Расскажи свой последний абзац в desktop ricing тредах. Сам я по ним не угораю, но когда-то написал опенсорную консольную программку, и пару раз ее видел на скринах анонов на форче, реддите, и даже на дваче, лол. Причем я уверен что как программа она им была не нужна, просто выглядела прикольно.
>>34926
Именно поэтому хочется лёгкую имплементацию ГДСкрипта, да хоть в лазарусе/дельфи как скрипт-компонент. Но лучше как отдельный компилятор. Чтобы да.
Именно поэтому хочется лёгкую имплементацию ГДСкрипта, да хоть в лазарусе/дельфи как скрипт-компонент. Но лучше как отдельный компилятор. Чтобы да.
>>34931
Мы обсуждали прикладное ПО, а не вкусы г@ймеров.
Ещё скажи, что RGB подсветочка суперпопулярна в офисных ПК больниц, где без RGB радужного CPU вентилятора врачи не могут работать с больными - отказываются работать на "скучном" компьютере.
В офисных ПК кастомизация ОС обычно запрещена. Пользователь ограничен необходимыми для работы программами и доступом к локальной сети офиса. Аналогично с ПК в школьных кабинетах, классах.
Алсо часть прикладных программ требуется работа в реальном времени. Не как "игры реального времени", а по-настоящему, чтоб ничто не могло съесть 10 мс в неожиданный момент времени. Тут не до красоты.
>>34934
По идее, самое тяжёлое в GDScript - динамическая типизация. Но от неё не будут избавляться... Как и переделывать GDScript в язык общего назначения.
Даже встроенный был бы хорош... Не в байт-код, а напрямую в машинный код или через какой-то C... Вариантов много, но ничего так и не выбрали (?).
>desktop ricing
>просто выглядела прикольно
Мы обсуждали прикладное ПО, а не вкусы г@ймеров.
Ещё скажи, что RGB подсветочка суперпопулярна в офисных ПК больниц, где без RGB радужного CPU вентилятора врачи не могут работать с больными - отказываются работать на "скучном" компьютере.
В офисных ПК кастомизация ОС обычно запрещена. Пользователь ограничен необходимыми для работы программами и доступом к локальной сети офиса. Аналогично с ПК в школьных кабинетах, классах.
Алсо часть прикладных программ требуется работа в реальном времени. Не как "игры реального времени", а по-настоящему, чтоб ничто не могло съесть 10 мс в неожиданный момент времени. Тут не до красоты.
>>34934
>хочется лёгкую имплементацию ГДСкрипта
По идее, самое тяжёлое в GDScript - динамическая типизация. Но от неё не будут избавляться... Как и переделывать GDScript в язык общего назначения.
>как отдельный компилятор
Даже встроенный был бы хорош... Не в байт-код, а напрямую в машинный код или через какой-то C... Вариантов много, но ничего так и не выбрали (?).
>>34975
Самое тяжёлое во всём годоте - тип Variant, он может быть чем угодно, включая любой класс годота, любая даже типизированная переменная это Variant, конкретно в gdscript почти всё делает одна огромная функция, https://github.com/godotengine/godot/blob/master/modules/gdscript/gdscript_vm.cpp
Можно сказать что это и есть динамическая типизация, но не только. Там наверняка какой то косяк в реализации, потому что есть другие примеры языков без типизации (js, php) которые обгонят gdscript очень сильно и будут потреблять в разы меньше памяти. Надеюсь репозиторий годота когда нибудь посетит гуру написания парсеров и интерпретаторов и хорошо им там наоптимизирует.
>По идее, самое тяжёлое в GDScript - динамическая типизация. Но от неё не будут избавляться... Как и переделывать GDScript в язык общего назначения.
Самое тяжёлое во всём годоте - тип Variant, он может быть чем угодно, включая любой класс годота, любая даже типизированная переменная это Variant, конкретно в gdscript почти всё делает одна огромная функция, https://github.com/godotengine/godot/blob/master/modules/gdscript/gdscript_vm.cpp
Можно сказать что это и есть динамическая типизация, но не только. Там наверняка какой то косяк в реализации, потому что есть другие примеры языков без типизации (js, php) которые обгонят gdscript очень сильно и будут потреблять в разы меньше памяти. Надеюсь репозиторий годота когда нибудь посетит гуру написания парсеров и интерпретаторов и хорошо им там наоптимизирует.
90 Кб, 639x715>>35002
Они всё равно сильно отстают от компилируемых.
Чем пытаться выжать всё из интерпретатора, лучше разработать/найти компилятор с оптимизациями...
Алсо, компиляция не обязана быть медленной. Вот Pascal компилируется быстро, и хоть и отстаёт от C, преимущество быстрой компиляции очевидно: раз нажал F9 и уже видишь на экране свою программу.
>примеры языков без типизации (js, php)
Они всё равно сильно отстают от компилируемых.
>гуру написания парсеров и интерпретаторов
Чем пытаться выжать всё из интерпретатора, лучше разработать/найти компилятор с оптимизациями...
Алсо, компиляция не обязана быть медленной. Вот Pascal компилируется быстро, и хоть и отстаёт от C, преимущество быстрой компиляции очевидно: раз нажал F9 и уже видишь на экране свою программу.
>>35002
Какой то упитанный пост, ну или ты реально не понимаешь, что js и php были ОЧЕ медленным языками, просто их движки переписывались по восемь раз миллионными мегакорпорациями.
Какой то упитанный пост, ну или ты реально не понимаешь, что js и php были ОЧЕ медленным языками, просто их движки переписывались по восемь раз миллионными мегакорпорациями.
>>35002
Ну ты сравнил. JS - мегаоптимизированный язык, в реализации которого влили кучу бабла мегакорпорации. А GDScript по твоей же ссылке пилится по сути одним человеком - vnen. Остальные только варнинги подпиливают да прочую мелочевку. Достаточно git blame глянуть. Для оптимизаций там поле непаханое.
>есть другие примеры языков без типизации (js, php) которые обгонят
Ну ты сравнил. JS - мегаоптимизированный язык, в реализации которого влили кучу бабла мегакорпорации. А GDScript по твоей же ссылке пилится по сути одним человеком - vnen. Остальные только варнинги подпиливают да прочую мелочевку. Достаточно git blame глянуть. Для оптимизаций там поле непаханое.
190 Кб, 592x353>>35013
Чо только растоидоры не высрут, лишь бы загнать народ на раст.
Чо только растоидоры не высрут, лишь бы загнать народ на раст.
>>35013
Да, но я ж не сравниваю с компилируемыми
Да, но они не откажутся от интерпретации, мне это очевидно
Опять компиляция, я про интерпретацию.
>>35016
Твой пост упитанный, bun сколько раз переписывался, что с бета версии быстрее существующих переписанных восемь миллионов раз движков?
>>35019
привел пример интерпретируемых языков которые очень быстро работают, питон специально не упоминаю т.к. вся его скорость обеспечена вызовом функций из нативных библиотек, в принципе как и в GDScript, но тут можно было докопаться.
>Они всё равно сильно отстают от компилируемых.
Да, но я ж не сравниваю с компилируемыми
>Чем пытаться выжать всё из интерпретатора, лучше разработать/найти компилятор с оптимизациями...
Да, но они не откажутся от интерпретации, мне это очевидно
>Вот Pascal компилируется быстро
Опять компиляция, я про интерпретацию.
>>35016
Твой пост упитанный, bun сколько раз переписывался, что с бета версии быстрее существующих переписанных восемь миллионов раз движков?
>>35019
привел пример интерпретируемых языков которые очень быстро работают, питон специально не упоминаю т.к. вся его скорость обеспечена вызовом функций из нативных библиотек, в принципе как и в GDScript, но тут можно было докопаться.
110 Кб, 700x483>>34834
Описываешь предмет инвентаря без количества:
И т.д. по необходимости. Потом сам инвентарь:
Описываешь предмет инвентаря без количества:
>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)
>>34834
Ну и можно int обернуть в ссылочный тип:
Тогда код немного изменится:
И т.д. Это если тебе обязательно ссылочки иметь.
Ну или объединить ItemData и ItemAmount...
Ну и можно int обернуть в ссылочный тип:
>class_name ItemAmount extends Resource
>@export var amount: int
Тогда код немного изменится:
>@export var store: Dictionary[ItemData, ItemAmount]
>...else: store[item].amount += amount
И т.д. Это если тебе обязательно ссылочки иметь.
Ну или объединить ItemData и ItemAmount...
>>35024
Питон кстати в последних версиях неплохо ускоряют, и над избавлением от гила работают, наканецта. Как и говорилось, ускорение реализуется вливанием мегабабла.
Питон кстати в последних версиях неплохо ускоряют, и над избавлением от гила работают, наканецта. Как и говорилось, ускорение реализуется вливанием мегабабла.
>>35052
Если б всё дело было в бабле, мы бы не сидели на Godot, не?..
Чисто по сырой ничем не прикрытой мощи Godot лидирует...
>Как и говорилось, ускорение реализуется вливанием мегабабла.
Если б всё дело было в бабле, мы бы не сидели на Godot, не?..
Чисто по сырой ничем не прикрытой мощи Godot лидирует...
>>35062
Сидим тут вопреки такой себе производительности гдскрипта, а не ради нее. Ну а кому надо шустро пишут в годоте на плюсах.
Сидим тут вопреки такой себе производительности гдскрипта, а не ради нее. Ну а кому надо шустро пишут в годоте на плюсах.
>>35062
Годот это подруга из молодости, с которой ты бухаешь и трахаешься по фану, а она еще и подкармливает бутербродиками. А юнька с уе - это корпоратская фемдом холодная мразь с флюгегехаймен в одной руке и оплатой в другой.
Годот это подруга из молодости, с которой ты бухаешь и трахаешься по фану, а она еще и подкармливает бутербродиками. А юнька с уе - это корпоратская фемдом холодная мразь с флюгегехаймен в одной руке и оплатой в другой.
Кто-нибудь работает на Godot с iGPU? Intel/AMD? Норм?
А то я смотрю на современные процессоры, и там 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, а потом жалуются на процессор...
А то я смотрю на современные процессоры, и там 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, а потом жалуются на процессор...
>>35079
Лень все читать, скажу что сделал 2д игру на трешке на ноуте 2012 года с интеловской встройкой, полет нормальный, до сих пор на итче качают. Чего там в четверке хз. Ну и смотря что ты делать собираешься, 2д, 3д, уровень детализации, и тд. Но я спать уже.
Просто скачай, накидай примерный проект из готовых ассетов, или запусти готовое годотовское демо, и посмотри.
Лень все читать, скажу что сделал 2д игру на трешке на ноуте 2012 года с интеловской встройкой, полет нормальный, до сих пор на итче качают. Чего там в четверке хз. Ну и смотря что ты делать собираешься, 2д, 3д, уровень детализации, и тд. Но я спать уже.
Просто скачай, накидай примерный проект из готовых ассетов, или запусти готовое годотовское демо, и посмотри.
>>35079
запускал 3д шеб игру на ноуте ~2012 года, все работало в шисят фпс
но там была микро-игра в 2 экрана
запускал 3д шеб игру на ноуте ~2012 года, все работало в шисят фпс
но там была микро-игра в 2 экрана
Нихуя не понял, так можно или нет взять ваш движок последней версии, слепить игру и не вставая с дивана экспортнуть сразу на пекарню, на ведро и на айфон?
>>35169
В теории да, можно всё разу, но:
Легче всего. Нужно только скачать export template. Собственный шаблон экспорта редко нужен на ПК - стандартные покрывают 99.99% возможных игр.
Нужно скачать OpenJDK и Android SDK и создать собственный ключ для подписи APK, потом - легко. Однако, для оптимизации под мобилки и каких-то дополнительных фич потребуется собирать всё из исходников - это немного сложнее, но нормально.
Честно, не пробовал, но Apple - анально огороженная платформа, требующая конпелировать iOS аппы на компьютере с macOS и Xcode, иначе они твоё дерьмо откажутся принимать в свой магазин говна. В общем, отвратительная платформа, что-то уровня соснолей - покупается лохами для своих мелких лошков, ибо в компьютерах они не шарят и учиться не хотят. Лучше просидеть всю жизнь на винде, чем мараться об мак.
Подробнее про экспорт читать тут:
https://docs.godotengine.org/en/stable/tutorials/export/index.html
>экспортнуть сразу
В теории да, можно всё разу, но:
>на пекарню
Легче всего. Нужно только скачать export template. Собственный шаблон экспорта редко нужен на ПК - стандартные покрывают 99.99% возможных игр.
>на ведро
Нужно скачать OpenJDK и Android SDK и создать собственный ключ для подписи APK, потом - легко. Однако, для оптимизации под мобилки и каких-то дополнительных фич потребуется собирать всё из исходников - это немного сложнее, но нормально.
>на айфон
Честно, не пробовал, но Apple - анально огороженная платформа, требующая конпелировать iOS аппы на компьютере с macOS и Xcode, иначе они твоё дерьмо откажутся принимать в свой магазин говна. В общем, отвратительная платформа, что-то уровня соснолей - покупается лохами для своих мелких лошков, ибо в компьютерах они не шарят и учиться не хотят. Лучше просидеть всю жизнь на винде, чем мараться об мак.
Подробнее про экспорт читать тут:
https://docs.godotengine.org/en/stable/tutorials/export/index.html
>>35396
Справдливости ради макос лучше винды, а макбук лучше дженерик ноутов. Как и айфон лучше андроида в среднем по больнице. Но сама компания где-то между размазанным говном на тарелке и конторой замечательных людей в виде ркн находится, это все портит.
Справдливости ради макос лучше винды, а макбук лучше дженерик ноутов. Как и айфон лучше андроида в среднем по больнице. Но сама компания где-то между размазанным говном на тарелке и конторой замечательных людей в виде ркн находится, это все портит.
>>35418
Макбук Про 2017 это худший ноутбук, которым я когда-либо владел за последние двадцать лет. Залипающие клавиши (некоторые буковки печатаются по два раза за нажатие), стертые за год надписи на клавишах как на самых дешевых клавиатурах с алиэкспресса, пластик на клавишах полируется и перестаёт быть матовым за тот же год (выглядит просто ублюдочно), пиратская винда поставленная параллельно стартовал быстрее, чем макось, шлейф соединения дисплея перетирается от открывания за тот же год и дисплей просто перестает работать (у проблемы даже официальное название есть, лол, flexgate, ремонт у официалов 600 евро). Ты не встретишь таких проблем ни у одного ноутбука даже за 100 баксов, а макбукокал стоил почти 2к евро. Эпплодауны умалчивают об этом, чтобы другие купились, как я например.
Никому не советую брать макбуки, даже если лишние деньги появятся. Это мусор, а не техника.
>макбук лучше дженерик ноутов
Макбук Про 2017 это худший ноутбук, которым я когда-либо владел за последние двадцать лет. Залипающие клавиши (некоторые буковки печатаются по два раза за нажатие), стертые за год надписи на клавишах как на самых дешевых клавиатурах с алиэкспресса, пластик на клавишах полируется и перестаёт быть матовым за тот же год (выглядит просто ублюдочно), пиратская винда поставленная параллельно стартовал быстрее, чем макось, шлейф соединения дисплея перетирается от открывания за тот же год и дисплей просто перестает работать (у проблемы даже официальное название есть, лол, flexgate, ремонт у официалов 600 евро). Ты не встретишь таких проблем ни у одного ноутбука даже за 100 баксов, а макбукокал стоил почти 2к евро. Эпплодауны умалчивают об этом, чтобы другие купились, как я например.
Никому не советую брать макбуки, даже если лишние деньги появятся. Это мусор, а не техника.
>>35418
Именно поэтому на макбуки устанавливают Винду?
Не бери звонилки за 1.5 т.р., если ты хочешь играть.
Android можно установить практически куда угодно, потому что это Linux с нескучным рабочим столом. Естественно, что это ведёт к бюджетным телефонам. Однако не всем людям нужен игровой смартфон или мессенджеры, браузерные приложения и подобное.
Просто игнорируй ньюфагов, купивших звонилку за стоимость двух походов за фастфудом, но при этом планирующих играть в 3D онлайн шутер с 60+ фпс... Покупать что-то в твоей игре они всё равно не будут.
>макос лучше винды, а макбук лучше дженерик
Именно поэтому на макбуки устанавливают Винду?
>айфон лучше андроида в среднем по больнице
Не бери звонилки за 1.5 т.р., если ты хочешь играть.
Android можно установить практически куда угодно, потому что это Linux с нескучным рабочим столом. Естественно, что это ведёт к бюджетным телефонам. Однако не всем людям нужен игровой смартфон или мессенджеры, браузерные приложения и подобное.
Просто игнорируй ньюфагов, купивших звонилку за стоимость двух походов за фастфудом, но при этом планирующих играть в 3D онлайн шутер с 60+ фпс... Покупать что-то в твоей игре они всё равно не будут.
>>35454
За то, что назвал их хуже ркн? Сколько же нефти отсыпают за похвалу пидорасам тогда?
За то, что назвал их хуже ркн? Сколько же нефти отсыпают за похвалу пидорасам тогда?
55 Кб, 604x352>>35463
За похвалу - Big Mac. Как Mac, но большой.
За похвалу - Big Mac. Как Mac, но большой.
336 Кб, 500x680Делайте игры
422 Кб, 1921x1080Сижу смотрю ютуб по гейдеву и что я вижу? Челик двумя if'ами кодит баунс квадрата от границ (в данном случае окна). Помню мы этот момент итт обсуждали и местные гейдевелоперы подключали физику с коллизиями чтобы избежать этих двух строк. Забавное совпадение.
>>35716
Идейное духовенство любителей переписывать архитектуру мультиплеерно-анти-антипаттерных кнопок ИТТ.
Идейное духовенство любителей переписывать архитектуру мультиплеерно-анти-антипаттерных кнопок ИТТ.
>>35716
У него весь канал базируется на стримах какого-нибудь ебанутого языка или ебанутой логики на стандартном языке, так что твой аргумент тут мимо кассы.
У него весь канал базируется на стримах какого-нибудь ебанутого языка или ебанутой логики на стандартном языке, так что твой аргумент тут мимо кассы.
>>35725
Я про маэстро BLOW
Я про маэстро BLOW
>>35728
Он из новосибирска или что-то в этом роде, даун.
Он из новосибирска или что-то в этом роде, даун.
>>35708
Т.к. пишет хэллоу ворлд на языке без библиотек.
Чтобы поле могло быть любой формы.
>>35716
Наоборот, сокобан - это тест компилятора.
https://jai.community/t/overview-of-jai/128
Любопытно, что он считает себя гением и трясётся:
Но даже не знает БАЗЫ велосипедокомпиляторов:
Все базированные языки компилируют компилятор.
https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
Если компилятор не компилирует сам себя, это фейл.
Ну а что по самому языку?
Т.е. оптимизируйте сами. На ассемблере. А ещё:
Т.е. игры предлагается делать как в 1980?
И на десерт:
Больше 10 лет ковыряет. Проект уровня TempleOS.
А по синтаксису это очередная копия C без плюсов.
Классический NIH-синдром в терминальной стадии.
>двумя if'ами кодит баунс квадрата от границ
Т.к. пишет хэллоу ворлд на языке без библиотек.
>подключали физику с коллизиями чтобы...
Чтобы поле могло быть любой формы.
>>35716
Наоборот, сокобан - это тест компилятора.
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-синдром в терминальной стадии.
>>35708
Т.к. пишет хэллоу ворлд на языке без библиотек.
Чтобы поле могло быть любой формы.
>>35716
Наоборот, сокобан - это тест компилятора.
https://jai.community/t/overview-of-jai/128
Любопытно, что он считает себя гением и трясётся:
Но даже не знает БАЗЫ велосипедокомпиляторов:
Все базированные языки компилируют компилятор.
https://en.wikipedia.org/wiki/Bootstrapping_(compilers)
Если компилятор не компилирует сам себя, это фейл.
Ну а что по самому языку?
Т.е. оптимизируйте сами. На ассемблере. А ещё:
Т.е. игры предлагается делать как в 1980?
И на десерт:
Больше 10 лет ковыряет. Проект уровня TempleOS.
А по синтаксису это очередная копия C без плюсов.
Классический NIH-синдром в терминальной стадии.
>двумя if'ами кодит баунс квадрата от границ
Т.к. пишет хэллоу ворлд на языке без библиотек.
>подключали физику с коллизиями чтобы...
Чтобы поле могло быть любой формы.
>>35716
Наоборот, сокобан - это тест компилятора.
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-синдром в терминальной стадии.
>>35822
Спасибо за подробный разбор. Аж жалко стало чела. Это реально болезнь какая-то.
Спасибо за подробный разбор. Аж жалко стало чела. Это реально болезнь какая-то.
>>35822
Даже я это знал, просто потому что прикольный факт такой. Хотя в языкописательстве я никто.
>Все базированные языки компилируют компилятор.
Даже я это знал, просто потому что прикольный факт такой. Хотя в языкописательстве я никто.
>>35822
Вообще никакой связи. Reference это языковая конструкция, а не имплементационная деталь. Наприер в c++ reference это подвид указателя, но с дополнительными ограничениями наложенными языком (не может быть null, отслеживание типа, кто им пользуется и т.д)
>No reference types (т.е. ВСЕ данные идут через стек)
Вообще никакой связи. Reference это языковая конструкция, а не имплементационная деталь. Наприер в c++ reference это подвид указателя, но с дополнительными ограничениями наложенными языком (не может быть null, отслеживание типа, кто им пользуется и т.д)
>>35832
Это абсолютно опциональная вещь, поскольку требует просто большого количества рутинной работы (написать все либы, которые могут быть не нужны для разработки игры).
Это абсолютно опциональная вещь, поскольку требует просто большого количества рутинной работы (написать все либы, которые могут быть не нужны для разработки игры).
>>35824
Так он аутист, в смысле ирл. Высрал 1 пазл за всю жизнь, который всё равно пришлось оптимизировать Кейси Муратори, но собрал вокруг себя сообщество нитакусиков которые его боготворят.
Так он аутист, в смысле ирл. Высрал 1 пазл за всю жизнь, который всё равно пришлось оптимизировать Кейси Муратори, но собрал вокруг себя сообщество нитакусиков которые его боготворят.
13 Кб, 414x188Пересобрал себе экспорт темплейт, теперь мой веб билд занимает 9мб в зипе.
>>35834
Да, согласен, перепутал немного. Просто с моей т.з. практической разницы между pointer и reference не существует. Это просто "ссылка на участок памяти". Непонятно, что имели в виду под "no reference type". Получается, нельзя класть ссылку в переменную?
Если рассмотреть абстрактный пример:
Здесь "reference" хранит ссылку на "number", но по определению "ссылкой" (pointer) является "@x", а вот "reference" имеет тип "Pointer" = "reference type". Нет? Получается, что в Jai не существует типа "Pointer", но допускается использовать запись типа "@variable"? Непонятно, зачем вводить подобные ограничения.
Меня всегда путали все эти ссылки/указатели... Щас попытался поискать, и LLM помощник тоже путается.
>>35837
Если твой компилятор не может скомпилировать компилятор, является ли он Тьюринг-полным? А то развелось тут "HTML программистов", понимаете.
Если серьёзно, написание компилятора на своём собственном языке позволяет протестировать язык, сэкономив на переключении между своим языком и посторонним языком, т.е. работать в одной среде. Разрабатывая Sokoban ты не работаешь над своим компилятором, хоть и тестируешь язык. Работая над компилятором на своём языке ты одновременно его разрабатываешь и тестируешь, не так ли? Поэтому бутстрапинг компилятора - база велосипедистов.
Ага, а ты как хотел? Изобрести язык без работы?
Во-первых, с большой вероятностью будут нужны.
Во-вторых, если очень лень - можно динамически линковаться с библиотеками на других языках. Или динамическая линковка для игр на новом языке не требуется? Будешь и физический 3D движок с нуля изобретать или всё-таки подключишь как DLL?
Но суть в том, что чем раньше ты начинаешь делать компилятор на своём языке, тем проще будет потом.
>>35856
Да пусть делает, что хочет. Как будто мы тут игры разрабатываем, лол. Каждый развлекается как ему нравится... Кто-то вот языки изобретает просто так.
Да, согласен, перепутал немного. Просто с моей т.з. практической разницы между 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 помощник тоже путается.
>>35837
>абсолютно опциональная вещь
Если твой компилятор не может скомпилировать компилятор, является ли он Тьюринг-полным? А то развелось тут "HTML программистов", понимаете.
Если серьёзно, написание компилятора на своём собственном языке позволяет протестировать язык, сэкономив на переключении между своим языком и посторонним языком, т.е. работать в одной среде. Разрабатывая Sokoban ты не работаешь над своим компилятором, хоть и тестируешь язык. Работая над компилятором на своём языке ты одновременно его разрабатываешь и тестируешь, не так ли? Поэтому бутстрапинг компилятора - база велосипедистов.
>большого количества рутинной работы
Ага, а ты как хотел? Изобрести язык без работы?
>написать все либы, которые могут быть не нужны
Во-первых, с большой вероятностью будут нужны.
Во-вторых, если очень лень - можно динамически линковаться с библиотеками на других языках. Или динамическая линковка для игр на новом языке не требуется? Будешь и физический 3D движок с нуля изобретать или всё-таки подключишь как DLL?
Но суть в том, что чем раньше ты начинаешь делать компилятор на своём языке, тем проще будет потом.
>>35856
Да пусть делает, что хочет. Как будто мы тут игры разрабатываем, лол. Каждый развлекается как ему нравится... Кто-то вот языки изобретает просто так.
>>35834
Да, согласен, перепутал немного. Просто с моей т.з. практической разницы между pointer и reference не существует. Это просто "ссылка на участок памяти". Непонятно, что имели в виду под "no reference type". Получается, нельзя класть ссылку в переменную?
Если рассмотреть абстрактный пример:
Здесь "reference" хранит ссылку на "number", но по определению "ссылкой" (pointer) является "@x", а вот "reference" имеет тип "Pointer" = "reference type". Нет? Получается, что в Jai не существует типа "Pointer", но допускается использовать запись типа "@variable"? Непонятно, зачем вводить подобные ограничения.
Меня всегда путали все эти ссылки/указатели... Щас попытался поискать, и LLM помощник тоже путается.
>>35837
Если твой компилятор не может скомпилировать компилятор, является ли он Тьюринг-полным? А то развелось тут "HTML программистов", понимаете.
Если серьёзно, написание компилятора на своём собственном языке позволяет протестировать язык, сэкономив на переключении между своим языком и посторонним языком, т.е. работать в одной среде. Разрабатывая Sokoban ты не работаешь над своим компилятором, хоть и тестируешь язык. Работая над компилятором на своём языке ты одновременно его разрабатываешь и тестируешь, не так ли? Поэтому бутстрапинг компилятора - база велосипедистов.
Ага, а ты как хотел? Изобрести язык без работы?
Во-первых, с большой вероятностью будут нужны.
Во-вторых, если очень лень - можно динамически линковаться с библиотеками на других языках. Или динамическая линковка для игр на новом языке не требуется? Будешь и физический 3D движок с нуля изобретать или всё-таки подключишь как DLL?
Но суть в том, что чем раньше ты начинаешь делать компилятор на своём языке, тем проще будет потом.
>>35856
Да пусть делает, что хочет. Как будто мы тут игры разрабатываем, лол. Каждый развлекается как ему нравится... Кто-то вот языки изобретает просто так.
Да, согласен, перепутал немного. Просто с моей т.з. практической разницы между 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 помощник тоже путается.
>>35837
>абсолютно опциональная вещь
Если твой компилятор не может скомпилировать компилятор, является ли он Тьюринг-полным? А то развелось тут "HTML программистов", понимаете.
Если серьёзно, написание компилятора на своём собственном языке позволяет протестировать язык, сэкономив на переключении между своим языком и посторонним языком, т.е. работать в одной среде. Разрабатывая Sokoban ты не работаешь над своим компилятором, хоть и тестируешь язык. Работая над компилятором на своём языке ты одновременно его разрабатываешь и тестируешь, не так ли? Поэтому бутстрапинг компилятора - база велосипедистов.
>большого количества рутинной работы
Ага, а ты как хотел? Изобрести язык без работы?
>написать все либы, которые могут быть не нужны
Во-первых, с большой вероятностью будут нужны.
Во-вторых, если очень лень - можно динамически линковаться с библиотеками на других языках. Или динамическая линковка для игр на новом языке не требуется? Будешь и физический 3D движок с нуля изобретать или всё-таки подключишь как DLL?
Но суть в том, что чем раньше ты начинаешь делать компилятор на своём языке, тем проще будет потом.
>>35856
Да пусть делает, что хочет. Как будто мы тут игры разрабатываем, лол. Каждый развлекается как ему нравится... Кто-то вот языки изобретает просто так.
>>35881
Я написал свой ответ на основании наблюдений за несколькими разрабатывающимися языками, например Zig стал self hosted только через 6 лет после создания. И это реально чисто работа только для этой работы. Язык там особо не испытывается, там обычно портянки однотипных свитчей. Это отдельная деятельность, писать все эти парсеры.
Я написал свой ответ на основании наблюдений за несколькими разрабатывающимися языками, например Zig стал self hosted только через 6 лет после создания. И это реально чисто работа только для этой работы. Язык там особо не испытывается, там обычно портянки однотипных свитчей. Это отдельная деятельность, писать все эти парсеры.
>>36026
Лол. А на C++ эти же портянки писать не будешь? Или разработчик языка только меняет обои на нескучные, создавая "новый язык" копипастой существующего?
Посмотрел Zig - опять какой-то клон C. Ну и зачем?..
Форт-машину лучше напишите. Можно на GDScript.
>портянки однотипных свитчей
Лол. А на C++ эти же портянки писать не будешь? Или разработчик языка только меняет обои на нескучные, создавая "новый язык" копипастой существующего?
Посмотрел Zig - опять какой-то клон C. Ну и зачем?..
Форт-машину лучше напишите. Можно на GDScript.
>>35024
Сходил посмотреть в вики
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 раза получается. В правильно поставленном вопросе - половина ответа!
>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 раза получается. В правильно поставленном вопросе - половина ответа!
>>36045
А я про с++ ничего и не писал. Я писал про то что "проверка" языка делается написанием разных хитрых языковых конструкций, а в компиляторе им обычно места и нет, это просто такой "библиотекарь" типа написано это - подставляем это.
На замену C (не с++), потому что у того слишком уж все устаревшее, начиная с макросов и отсутствия перегрузок функций. И RAII.
А я про с++ ничего и не писал. Я писал про то что "проверка" языка делается написанием разных хитрых языковых конструкций, а в компиляторе им обычно места и нет, это просто такой "библиотекарь" типа написано это - подставляем это.
> Zig - опять какой-то клон C.
На замену C (не с++), потому что у того слишком уж все устаревшее, начиная с макросов и отсутствия перегрузок функций. И RAII.
Короче это я опять >>35169
Так и не смог найти нормального туториала по мобайл гейм девелопменту на годоте, со встройкой рекламы, оплаты етц на обе мобильные платформы. Если есть кто итт знающий, подскажите плз.
Так и не смог найти нормального туториала по мобайл гейм девелопменту на годоте, со встройкой рекламы, оплаты етц на обе мобильные платформы. Если есть кто итт знающий, подскажите плз.
>>36213
Ты геймдевить вообще умеешь? Сколько игр сделал? Если нет, то
тебе пока рано делать, попробуй сначала просто игру смастерить.
Для встраивания сервисов 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
Алсо, если ты это ради бабла, то без бюджета ничего не выйдет.
На мобилках зарабатывает тот, у кого уже есть деньги на рекламу.
Ты геймдевить вообще умеешь? Сколько игр сделал? Если нет, то
>со встройкой рекламы, оплаты етц на обе мобильные платформы
тебе пока рано делать, попробуй сначала просто игру смастерить.
Для встраивания сервисов 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
Алсо, если ты это ради бабла, то без бюджета ничего не выйдет.
На мобилках зарабатывает тот, у кого уже есть деньги на рекламу.
>>34694
Сделал тест 2D анимации на Godot 3.6.1. CPU 14%, GPU 7%, вроде нормально, но я ещё не добавил ни шрифт, ни взаимодействия. И как же всё-таки не хочется что-то делать снова на 3.x... Это такой сильный даунгрейд и редактора, и GDScript. Когда я переходил с 3.4/3.5 на 4.0+, мне казалось, что практически ничего не поменялось или поменялось в худшую сторону. Но теперь понимаю, что прогресс в юзабилити редактора всё-таки был...
>а еще я бы для мобилки делал на 3.6
Сделал тест 2D анимации на Godot 3.6.1. CPU 14%, GPU 7%, вроде нормально, но я ещё не добавил ни шрифт, ни взаимодействия. И как же всё-таки не хочется что-то делать снова на 3.x... Это такой сильный даунгрейд и редактора, и GDScript. Когда я переходил с 3.4/3.5 на 4.0+, мне казалось, что практически ничего не поменялось или поменялось в худшую сторону. Но теперь понимаю, что прогресс в юзабилити редактора всё-таки был...
>>36213
И без опыта, и чтобы убийца гта и майнкрафта в одном флаконе. Еще и шобы на нинтедно свищ 2. И санкции чтобы мы обошли для тебя.
Просто сделай хоть какую-нибудь базовую игру и выложи ее куда-нибудь типа итча. Тебе этого задания хватит на полгода.
И без опыта, и чтобы убийца гта и майнкрафта в одном флаконе. Еще и шобы на нинтедно свищ 2. И санкции чтобы мы обошли для тебя.
Просто сделай хоть какую-нибудь базовую игру и выложи ее куда-нибудь типа итча. Тебе этого задания хватит на полгода.
>>36228
Решил эту проблему не переходя на четверку. Но очень хочется. Вы там со своими фичами совсем охуели, а сижу тут, как фуфел, допиливаю.
Решил эту проблему не переходя на четверку. Но очень хочется. Вы там со своими фичами совсем охуели, а сижу тут, как фуфел, допиливаю.
>>36241
Он, видать, кобанчик - заработать хочет. Ему некогда. Подскочил, понимаете, чтобы по-быстрому налутать баблишка с детишек, а тут туториалы не находятся - непорядок, нужно срочно искать план Б, иначе конец.
>>36244
Дааа... Честно, не понимаю, зачем Godot'у вся эта "монолитность". Бамп мажорной версии был из-за рендеринга в основном: GLES2 дропнули и GLES3 переделали с нуля (с ошибками), сделали Vulkan... Собственно, почему нельзя вынести рендеринг в независимый от ядра движка модуль? Чтобы кому необходимо, подключал то, что ему необходимо. И пользовался актуальной версией GUI + GDScript. Аргументируют производительностью, но на мой субъективный взгляд, монолит весом 150 Мб будет медленным по определению... DLLки существуют с прошлого века, их наверяка уже оптимизировали.
У меня давно была мечта сделать "Лего"-движок, кастомизируемый без компиляции. Просто накидал модулей в виде DLLок в папку и всё работает. Вроде некоторые игры имеют под два десятка DLL и всё нормально работает, не? GDNative/GDExtension вроде подобное позволяет сделать с аддонами, но аддоны добавляются к жирному монолитному ядру... Можно попробовать раздробить это ядро, но я не шарю в программировании на C++ в достаточной мере...
Кагбэ, насколько мне известно (собирал свои DLL), производительность снижается только в момент подключения, когда ОС ищет и соединяет все эти невидимые "провода" между разными функциями. Непосредственно рантайм вроде бы не страдает.
Поискал в интернете:
https://stackoverflow.com/questions/9456635/
Думаю, стоит попробовать раздробить Godot на DLL.
Бонус: это может помочь удалить 3D без компиляции. Большинство игр всё равно 2D от зелёных новичков. Экспортные шаблоны нужно заново компилировать только на платформах типа мобильных, где один APK (теоретически, Android поддерживает что-то типа DLL; практически, для игрового движка это невыгодно).
Он, видать, кобанчик - заработать хочет. Ему некогда. Подскочил, понимаете, чтобы по-быстрому налутать баблишка с детишек, а тут туториалы не находятся - непорядок, нужно срочно искать план Б, иначе конец.
>>36244
Дааа... Честно, не понимаю, зачем 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; практически, для игрового движка это невыгодно).
>>36241
Он, видать, кобанчик - заработать хочет. Ему некогда. Подскочил, понимаете, чтобы по-быстрому налутать баблишка с детишек, а тут туториалы не находятся - непорядок, нужно срочно искать план Б, иначе конец.
>>36244
Дааа... Честно, не понимаю, зачем Godot'у вся эта "монолитность". Бамп мажорной версии был из-за рендеринга в основном: GLES2 дропнули и GLES3 переделали с нуля (с ошибками), сделали Vulkan... Собственно, почему нельзя вынести рендеринг в независимый от ядра движка модуль? Чтобы кому необходимо, подключал то, что ему необходимо. И пользовался актуальной версией GUI + GDScript. Аргументируют производительностью, но на мой субъективный взгляд, монолит весом 150 Мб будет медленным по определению... DLLки существуют с прошлого века, их наверяка уже оптимизировали.
У меня давно была мечта сделать "Лего"-движок, кастомизируемый без компиляции. Просто накидал модулей в виде DLLок в папку и всё работает. Вроде некоторые игры имеют под два десятка DLL и всё нормально работает, не? GDNative/GDExtension вроде подобное позволяет сделать с аддонами, но аддоны добавляются к жирному монолитному ядру... Можно попробовать раздробить это ядро, но я не шарю в программировании на C++ в достаточной мере...
Кагбэ, насколько мне известно (собирал свои DLL), производительность снижается только в момент подключения, когда ОС ищет и соединяет все эти невидимые "провода" между разными функциями. Непосредственно рантайм вроде бы не страдает.
Поискал в интернете:
https://stackoverflow.com/questions/9456635/
Думаю, стоит попробовать раздробить Godot на DLL.
Бонус: это может помочь удалить 3D без компиляции. Большинство игр всё равно 2D от зелёных новичков. Экспортные шаблоны нужно заново компилировать только на платформах типа мобильных, где один APK (теоретически, Android поддерживает что-то типа DLL; практически, для игрового движка это невыгодно).
Он, видать, кобанчик - заработать хочет. Ему некогда. Подскочил, понимаете, чтобы по-быстрому налутать баблишка с детишек, а тут туториалы не находятся - непорядок, нужно срочно искать план Б, иначе конец.
>>36244
Дааа... Честно, не понимаю, зачем 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; практически, для игрового движка это невыгодно).
>>36533
Маршалинг. Чтобы вызвать функцию из другого модуля, надо создать структуру, туда записать аргументы, контекст, передать. Если аргументы проходят через цепочку функций, умножается. Вот на этом производительность и съедается. Скомпилированный монолит будет оптимизирован компилятором так, что там целые цепочки вызовов будут выкинуты.
Маршалинг. Чтобы вызвать функцию из другого модуля, надо создать структуру, туда записать аргументы, контекст, передать. Если аргументы проходят через цепочку функций, умножается. Вот на этом производительность и съедается. Скомпилированный монолит будет оптимизирован компилятором так, что там целые цепочки вызовов будут выкинуты.
>>36537
Эм, я не понимаю, о чём ты говоришь... Объекты ведь остаются без изменений, вся разрица в том, когда код получает необходимые ему ссылки для прыжков.
Сразу скажу, мой основной опыт компилируемых ЯП состоит из вариантов 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-ключи", различные модули и т.п. У меня несколько таких приложений на телефоне есть... Для игрового движка такое вряд ли имеет смысл, правда, поскольку эти приложения скачиваются отдельно.
Эм, я не понимаю, о чём ты говоришь... Объекты ведь остаются без изменений, вся разрица в том, когда код получает необходимые ему ссылки для прыжков.
Сразу скажу, мой основной опыт компилируемых ЯП состоит из вариантов 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-ключи", различные модули и т.п. У меня несколько таких приложений на телефоне есть... Для игрового движка такое вряд ли имеет смысл, правда, поскольку эти приложения скачиваются отдельно.
>>36537
Эм, я не понимаю, о чём ты говоришь... Объекты ведь остаются без изменений, вся разрица в том, когда код получает необходимые ему ссылки для прыжков.
Сразу скажу, мой основной опыт компилируемых ЯП состоит из вариантов 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-ключи", различные модули и т.п. У меня несколько таких приложений на телефоне есть... Для игрового движка такое вряд ли имеет смысл, правда, поскольку эти приложения скачиваются отдельно.
Эм, я не понимаю, о чём ты говоришь... Объекты ведь остаются без изменений, вся разрица в том, когда код получает необходимые ему ссылки для прыжков.
Сразу скажу, мой основной опыт компилируемых ЯП состоит из вариантов 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-ключи", различные модули и т.п. У меня несколько таких приложений на телефоне есть... Для игрового движка такое вряд ли имеет смысл, правда, поскольку эти приложения скачиваются отдельно.
>>36566
Ему не надо выполнять шаги по укладыванию в стек, над контролируемым кодом, компилятор имеет право выдать выполняющий эквивалентные операции.
Пример - он вообще не вызывает функции, хотя они есть, он заинлайнил вычисления. Я ему еще усложнил задачу, заставив брать ввод из командной строки и записывать якобы в многопоточную переменную. Иначе он просто всю программу схлопывает до вывода константы.
Ему не надо выполнять шаги по укладыванию в стек, над контролируемым кодом, компилятор имеет право выдать выполняющий эквивалентные операции.
Пример - он вообще не вызывает функции, хотя они есть, он заинлайнил вычисления. Я ему еще усложнил задачу, заставив брать ввод из командной строки и записывать якобы в многопоточную переменную. Иначе он просто всю программу схлопывает до вывода константы.
>>36559
"Изучение Godot" не равно "изучению подключения рекламных площадок и платёжных операторов к программам на мобильных платформах". Если очень требуется подключить всё это, лучше обращаться к документации Google, Apple, рекламных площадок - основное там будет идентично для любого движка.
Как подключить всё это к Godot? Так, как обычно.
Но если ты вообще в Godot не разбираешься, куда подключать рекламу и донаты? Сделай игру, потом будешь подключать к ней всё, что нужно. Люди это определённо уже делали, т.е. возможность есть.
Если тебе нужно поскорее и без проблем - лучше уж выкупить уже готовое приложение, находящееся в магазинах, у его владельца. Т.е. ты получаешь все необходимые права и будущую прибыль. Издатели приблизительно так и делают - перекупают игры.
>Если это не тред изучения Godot
"Изучение Godot" не равно "изучению подключения рекламных площадок и платёжных операторов к программам на мобильных платформах". Если очень требуется подключить всё это, лучше обращаться к документации Google, Apple, рекламных площадок - основное там будет идентично для любого движка.
Как подключить всё это к Godot? Так, как обычно.
Но если ты вообще в Godot не разбираешься, куда подключать рекламу и донаты? Сделай игру, потом будешь подключать к ней всё, что нужно. Люди это определённо уже делали, т.е. возможность есть.
Если тебе нужно поскорее и без проблем - лучше уж выкупить уже готовое приложение, находящееся в магазинах, у его владельца. Т.е. ты получаешь все необходимые права и будущую прибыль. Издатели приблизительно так и делают - перекупают игры.
>>36587
P.s. но это касается подконтрольного кода. Там где он не знает - происходит как ты говоришь, укладывание на стек и вызов функции printf, она черный ящик.
P.s. но это касается подконтрольного кода. Там где он не знает - происходит как ты говоришь, укладывание на стек и вызов функции printf, она черный ящик.
>>36559
Идешь в ассеты, вбиваешь что нужно
Потом идешь там по кнопочке View Files
Попадаешь в гитхаб, читаешь issues если есть
У меня какой то такой воркфлоу обычно.
>Туториал
Идешь в ассеты, вбиваешь что нужно
Потом идешь там по кнопочке View Files
Попадаешь в гитхаб, читаешь issues если есть
У меня какой то такой воркфлоу обычно.
>>36587
Это как-то неправильно... Из-за этого могут быть проблемы, как минимум - несовместимости.
Ты вызвал компилятор с флагом -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. Бррр, лучше бы я об этом вообще не знал...
>компилятор имеет право выдать выполняющий эквивалентные операции
Это как-то неправильно... Из-за этого могут быть проблемы, как минимум - несовместимости.
>Пример - он вообще не вызывает функции, хотя они есть, он заинлайнил
Ты вызвал компилятор с флагом -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. Бррр, лучше бы я об этом вообще не знал...
>>36587
Это как-то неправильно... Из-за этого могут быть проблемы, как минимум - несовместимости.
Ты вызвал компилятор с флагом -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. Бррр, лучше бы я об этом вообще не знал...
>компилятор имеет право выдать выполняющий эквивалентные операции
Это как-то неправильно... Из-за этого могут быть проблемы, как минимум - несовместимости.
>Пример - он вообще не вызывает функции, хотя они есть, он заинлайнил
Ты вызвал компилятор с флагом -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. Бррр, лучше бы я об этом вообще не знал...
Искал я себе удобный редактор пиксельных шрифтов на замену битфонтмейкеру. И нашел. А он на годоте - https://github.com/molarmanful/bited
>>36684
Йеее! Вперёд, Годот!
Йеее! Вперёд, Годот!
410 Кб, 2560x1600Нашел я программку для перегонки 3д в спрайты, а она на годоте: https://github.com/bukkbeek/GodotPixelRenderer
>>37484 (Del)
Да-да... До встречи послезавтра.
Никто не может гарантировать, что при агрессивных оптимизациях компилятор не взглянет на то как используется рандом, обнаружит, что рандом используется пять раз со статичным сидом, то есть, при каждом запуске прога получает от рандома 5 одинаковых "случайных" чисел, и компилятор просто зашьёт эти числа в экзешник.
> последний пост на борде, больше тут вряд ли буду появляться
Да-да... До встречи послезавтра.
> Нет, ничего общего с таким бредом нет. Рандом работает как раньше
Никто не может гарантировать, что при агрессивных оптимизациях компилятор не взглянет на то как используется рандом, обнаружит, что рандом используется пять раз со статичным сидом, то есть, при каждом запуске прога получает от рандома 5 одинаковых "случайных" чисел, и компилятор просто зашьёт эти числа в экзешник.
Открыл для себя годот веб эдитор
Казалось бы нахер он нужен, но я на своей блядской работе не могу даже установить что-нибудь на комп, мне просто не дают права админа
А теперь я могу хоть что-то делать, потихоньку двигаться
Казалось бы нахер он нужен, но я на своей блядской работе не могу даже установить что-нибудь на комп, мне просто не дают права админа
А теперь я могу хоть что-то делать, потихоньку двигаться
>>37522
А нахрена тебе права админа для годота? Скачал и запустил, он будет работать прямо так. Вскод, дотнет - туда же, их можно поставить без админа. Вот моно без админа не поставить без бубна, это да
А нахрена тебе права админа для годота? Скачал и запустил, он будет работать прямо так. Вскод, дотнет - туда же, их можно поставить без админа. Вот моно без админа не поставить без бубна, это да
>>37522
Подойди к сисадмину и попроси добавить годо в локальную политику или сделать тебе вторую учётуку на компе где он будет доступен, если нормальные отношения. Если с персональными данными работаете, в принципе он может отказать и это нормально, есть вариант попросить поставить виртуальную машину а там чтобы полные права у тебя были, переключение между ВМ и хостом - за секунду.
Подойди к сисадмину и попроси добавить годо в локальную политику или сделать тебе вторую учётуку на компе где он будет доступен, если нормальные отношения. Если с персональными данными работаете, в принципе он может отказать и это нормально, есть вариант попросить поставить виртуальную машину а там чтобы полные права у тебя были, переключение между ВМ и хостом - за секунду.
>>37498
>>37393
Нашел я программу для читает с бумажки молекулярного редактирования и физической симуляции нанодевайсов, а она на Годоте: https://msep.one
Можете в следующую шапку пихнуть.
>>37393
Нашел я программу для читает с бумажки молекулярного редактирования и физической симуляции нанодевайсов, а она на Годоте: https://msep.one
Можете в следующую шапку пихнуть.
1,3 Мб, mp4,720x406, 1:02
>>37528
Ебать оно трясется.
Ебать оно трясется.
>>37536 (Del)
Кейс nginx'а - это другое (азаза), 8 лет это никого не интересовало, особенно сам Рамблер, а как только сбербанк купил рамблер Сысоеву начали предъявлять.
Кейс nginx'а - это другое (азаза), 8 лет это никого не интересовало, особенно сам Рамблер, а как только сбербанк купил рамблер Сысоеву начали предъявлять.
>>37536 (Del)
Так и представил как кабанчик отжимает у анона его пиксельный платформер на флипнутых ассетах. Такая ценность.
>>37522
Годот еще на мобилках есть. Регулярно вижу на реддите посты от детей, которые ляпают свои игры прямо на телефонах, и код пишут там же.
Так и представил как кабанчик отжимает у анона его пиксельный платформер на флипнутых ассетах. Такая ценность.
>>37522
Годот еще на мобилках есть. Регулярно вижу на реддите посты от детей, которые ляпают свои игры прямо на телефонах, и код пишут там же.
А у нас итт тоже ведь был анон, делающий нсфв. Помню пиксельную тянку со скелетной анимацией, которая хуи сосала в гигахруще.
>>37524
Да, ты прав, он не требует прав админа же
Мб попробую скачать, но боюсь что палева будет больше
С другой стороны пока в мой монитор редко смотрят прям
Да, ты прав, он не требует прав админа же
Мб попробую скачать, но боюсь что палева будет больше
С другой стороны пока в мой монитор редко смотрят прям
>>37526
Пока слишком мало тут работаю для таких просьб сисьадмину
>>37536 (Del)
Это залупа для потеряных душ лет 40ка
Работают одни тети сраки, не думаю что кто-то спиздит мои три куба в редакторе
Пока слишком мало тут работаю для таких просьб сисьадмину
>>37536 (Del)
Это залупа для потеряных душ лет 40ка
Работают одни тети сраки, не думаю что кто-то спиздит мои три куба в редакторе
>>37615
Мне кажется, на мобиле будет очень неудобно
Лучше уж пересилить себя и дома посидеть над игрой
Мне кажется, на мобиле будет очень неудобно
Лучше уж пересилить себя и дома посидеть над игрой
>>37765
На завод таких как мы не примут. Собес не пройдём. А некоторые ещё и медкомиссию.
На завод таких как мы не примут. Собес не пройдём. А некоторые ещё и медкомиссию.
18,4 Мб, mp4,1304x720, 1:30
>>37654
О это я. Я бросил делать про гигахрущ потому что изначально вместо кода написал говно, фикся один баг, создавал новый, всё со всем было взаимосвязано, насрано и неудобно, проще забить. И ещё понял что писать сюжет, диалоги и мир очень сложно простому чувачку. Ещё я по сути там не определился че вообще хотел делать. Кароч проще убить новорожденного.
И ещё деньги на еду закончились и пришлось буквально пиздошить на завод, но ща вот скопил сверху денежек и съебался неделю назад, поэтому полностью занялся новой нсфв игрушкой, где арт, сюжет и диалоги пишет и рисует другой челик.
А так после гигахруща я ещё пытался на говняндекс играх заработать сделав платформер про самурая, но в него никто не поиграл и площадка сама удалила игру. Заработал с рекламы гдет косарь, но в саму рекламу вбухал 10 косарей. Ну как всегда кароч, поэтому на завод ушел. Может в ближайшее время снова придется пойти, потому что мама ругается заебала
О это я. Я бросил делать про гигахрущ потому что изначально вместо кода написал говно, фикся один баг, создавал новый, всё со всем было взаимосвязано, насрано и неудобно, проще забить. И ещё понял что писать сюжет, диалоги и мир очень сложно простому чувачку. Ещё я по сути там не определился че вообще хотел делать. Кароч проще убить новорожденного.
И ещё деньги на еду закончились и пришлось буквально пиздошить на завод, но ща вот скопил сверху денежек и съебался неделю назад, поэтому полностью занялся новой нсфв игрушкой, где арт, сюжет и диалоги пишет и рисует другой челик.
А так после гигахруща я ещё пытался на говняндекс играх заработать сделав платформер про самурая, но в него никто не поиграл и площадка сама удалила игру. Заработал с рекламы гдет косарь, но в саму рекламу вбухал 10 косарей. Ну как всегда кароч, поэтому на завод ушел. Может в ближайшее время снова придется пойти, потому что мама ругается заебала
Как избежать задвоения и затроения события при нажатии кнопки и одновременном двигания мышки?
func _unhandled_input(_event):
if Input.is_action_pressed(&"toggle_inventory"):
inventory.visible = not inventory.visible
Оно срабатывает много раз, я понимаю что там срутся ивенты от мышки, но есть же какой то правильный путь?
Попробовал _input и is_action_just_pressed - то же самое
проверять что event = InputEventKey - не помогает, при нажатии пары кнопок на клавиатуре такой же эффект
func _unhandled_input(_event):
if Input.is_action_pressed(&"toggle_inventory"):
inventory.visible = not inventory.visible
Оно срабатывает много раз, я понимаю что там срутся ивенты от мышки, но есть же какой то правильный путь?
Попробовал _input и is_action_just_pressed - то же самое
проверять что event = InputEventKey - не помогает, при нажатии пары кнопок на клавиатуре такой же эффект
>>37835
Всё, разобрался случайно, работает event.is_action_pressed
Всё, разобрался случайно, работает event.is_action_pressed
>>37834
Рад что ты еще с нами. Пости иногда свои поделки.
Традиционно посоветую сделать небольшую, четко нацеленную игру. Скоп крип это болезнь, способная убить лучших из нас.
Рад что ты еще с нами. Пости иногда свои поделки.
>И ещё понял что писать сюжет, диалоги и мир очень сложно простому чувачку.
Традиционно посоветую сделать небольшую, четко нацеленную игру. Скоп крип это болезнь, способная убить лучших из нас.
>>37842
А я не прекращал, да и прост ща занимаюсь одной конкретной, а там показывать по сути пока нечего, да и показывать каждый пук тоже неправильно. А так вот две другие игры которые делал после дропа гигахруща:
Пиксельную как раз на яндекс выложил, считаю она заебись, нужно только дальше развить и шлефовать, как-то зациклить геймплей и тп. И как-то пропиарить естесно. Но мне лень.
А 3д это будущая игра мечты, ммо экшн с боевой системой из академии джедаев, но я пока тупой и застрял в одном месте, да и занят другим.
>Пости иногда свои поделки
А я не прекращал, да и прост ща занимаюсь одной конкретной, а там показывать по сути пока нечего, да и показывать каждый пук тоже неправильно. А так вот две другие игры которые делал после дропа гигахруща:
Пиксельную как раз на яндекс выложил, считаю она заебись, нужно только дальше развить и шлефовать, как-то зациклить геймплей и тп. И как-то пропиарить естесно. Но мне лень.
А 3д это будущая игра мечты, ммо экшн с боевой системой из академии джедаев, но я пока тупой и застрял в одном месте, да и занят другим.
>>37860
Ты случаем не из киберкотлет по жашке? А то у нас так то очень тесное комьюнити и почти все айтишники как раз. Просто еще хз кому могла вспомниться именно боевая система оттуда.
>ммо экшн с боевой системой из академии джедаев
Ты случаем не из киберкотлет по жашке? А то у нас так то очень тесное комьюнити и почти все айтишники как раз. Просто еще хз кому могла вспомниться именно боевая система оттуда.
>>37872
Вертекс есть или был в качестве клона в плане боевки, но там сразу дисней прискакал с авторскимим, так что им пришлось убирать намеки на зв. Хотя он вроде даже бесплатный. Можно было раньше потрогать точно раньше, щас хз, ну в любом мслучае он чето как-то не прижился. Я к чему это - за продолжение дисней выебет.
Вертекс есть или был в качестве клона в плане боевки, но там сразу дисней прискакал с авторскимим, так что им пришлось убирать намеки на зв. Хотя он вроде даже бесплатный. Можно было раньше потрогать точно раньше, щас хз, ну в любом мслучае он чето как-то не прижился. Я к чему это - за продолжение дисней выебет.
У меня у одного люто пригорает пердак от того что все стараются запилить клон/продолжение полюбившейся игры, а потом трясутся от лицензионных рисков?
Конечно, хочется встретиться ещё раз с полюбившимися героями, но это путь в никуда.
Делайте свои сеттинги.
Конечно, хочется встретиться ещё раз с полюбившимися героями, но это путь в никуда.
Делайте свои сеттинги.
>>37893
Зато сам наешься пока делаешь.
А свои сеттинги это сложно. Ворлдбилдинг там, персонажи запоминающиеся, лор и все дела.
Зато сам наешься пока делаешь.
А свои сеттинги это сложно. Ворлдбилдинг там, персонажи запоминающиеся, лор и все дела.
>>37902
Ну, наверное другим и вправду сложно. Я-то с детства ворлдбилдинг практикую. Наверное уже и не вижу, насколько это сложно со стороны.
Ну, наверное другим и вправду сложно. Я-то с детства ворлдбилдинг практикую. Наверное уже и не вижу, насколько это сложно со стороны.
>>37909
В доцифровую эпоху и рисовал бывало, да. Нынче Азгаар'генератор мои потребности полностью закрывает. Остаётся только названия городов фиксить и дороги подрисовывать. А потом закрываешь глаза и... поехал. На телеге, запряжённой единорогами.
В доцифровую эпоху и рисовал бывало, да. Нынче Азгаар'генератор мои потребности полностью закрывает. Остаётся только названия городов фиксить и дороги подрисовывать. А потом закрываешь глаза и... поехал. На телеге, запряжённой единорогами.
>>37910
Искал я инструменты мапмейкинга, а они все на годоте!
1-2 - wondeercraft
3 - dungeoncraft
4 - Canvas of Kings
>Нынче Азгаар'генератор мои потребности полностью закрывает
Искал я инструменты мапмейкинга, а они все на годоте!
1-2 - wondeercraft
3 - dungeoncraft
4 - Canvas of Kings
Как сделать нормальный NavigationRegion3D с прямоходящими NavigationAgent3D? Или ждать че там в 4.5 намутят?
В игре НПС умеют прыгать в высоту на 1 метр, но часто застревают на углах, обходить друг друга не умеют, несмотря на Avoiding (исправил проверкой рейкастом и созданием нового таргета в радиусе от другого нпс, а потом построить путь к изначальной цели). Всё вроде бы работает, но в некоторых местах, например на сложном ландшафте, таргеты багуются, НПС останавливается и не может зацепиться ногами за землю... Короче, залупа получается, а ведь хотел ещё научить неписей паркурить, взбираться на уступы, карабкаться по стенам, прокладывать сложные маршруты с "умным выбором" (например, для нормального человека адекватнее будет пройти по дороге, чем прыгать с дерева на дерево как обезьяна или с крыши на крышу как ассасин).
Назрел вопрос: Как сделать нпс, который сможет паркурить по нескриптовой местности? Чтобы в локациях не нужно было вручную расставлять объекты, на которых триггерился бы скрипт "залезть на уступ" и было возможно даже на рандомно сгенеренной локе перемещаться неписю по сложным маршрутам.
Вот сгенерил я локацию "Горный лес" и у НПС "скалолаз" есть цель - дойти до вершины горы. Скалолаз обходит деревья, лазает по скалодромам, переходит через реки по упавшим брёвнам и всё это сгенеренно или, как минимум, расставлено без дополнительных объектов-триггеров.
Писать код за меня не прошу, но хотя бы объяснить как такое можно напрогать.
В игре НПС умеют прыгать в высоту на 1 метр, но часто застревают на углах, обходить друг друга не умеют, несмотря на Avoiding (исправил проверкой рейкастом и созданием нового таргета в радиусе от другого нпс, а потом построить путь к изначальной цели). Всё вроде бы работает, но в некоторых местах, например на сложном ландшафте, таргеты багуются, НПС останавливается и не может зацепиться ногами за землю... Короче, залупа получается, а ведь хотел ещё научить неписей паркурить, взбираться на уступы, карабкаться по стенам, прокладывать сложные маршруты с "умным выбором" (например, для нормального человека адекватнее будет пройти по дороге, чем прыгать с дерева на дерево как обезьяна или с крыши на крышу как ассасин).
Назрел вопрос: Как сделать нпс, который сможет паркурить по нескриптовой местности? Чтобы в локациях не нужно было вручную расставлять объекты, на которых триггерился бы скрипт "залезть на уступ" и было возможно даже на рандомно сгенеренной локе перемещаться неписю по сложным маршрутам.
Вот сгенерил я локацию "Горный лес" и у НПС "скалолаз" есть цель - дойти до вершины горы. Скалолаз обходит деревья, лазает по скалодромам, переходит через реки по упавшим брёвнам и всё это сгенеренно или, как минимум, расставлено без дополнительных объектов-триггеров.
Писать код за меня не прошу, но хотя бы объяснить как такое можно напрогать.
>>37991
заходишь в настройки проекта, ищешь глобальные переменные (автозагрузка), в них добавляешь свой скрипт с нужными переменными.
заходишь в настройки проекта, ищешь глобальные переменные (автозагрузка), в них добавляешь свой скрипт с нужными переменными.
>>38009
Справа ты должен был придумать имя узла, например, global_script. В другом скрипте если нужно значение из глобального скрипта, пишешь global_script.variable_name, если вызываешь метод, пишешь global_script.method_name()
Ты новичок? Как-то нежно пишешь код.
Справа ты должен был придумать имя узла, например, global_script. В другом скрипте если нужно значение из глобального скрипта, пишешь global_script.variable_name, если вызываешь метод, пишешь global_script.method_name()
Ты новичок? Как-то нежно пишешь код.
81 Кб, 1186x626у меня есть треугольник (шипы), при столкновении с которым игрок должен умирать, он должен быть отдельной сценой и Area2D? . не думаю что это правильный подход. потому что придется переносить каждый треугольник на сцену по одному, а у меня будет их много и я хочу рисовать ими через tilemap. что делать?
>>38013
Сделай ариа2д без спрайта и просто растягивай по области, где у тебя затайлены шипы
Сделай ариа2д без спрайта и просто растягивай по области, где у тебя затайлены шипы
>>38009
Давненько не видел нулевых в говнокодинге. Даже хз че посоветовать.
Ну а так у твоего синглтона имя есть, которое ты сам ему даешь, по нему и обращайся.
Давненько не видел нулевых в говнокодинге. Даже хз че посоветовать.
Ну а так у твоего синглтона имя есть, которое ты сам ему даешь, по нему и обращайся.
Хочу скомпилировать проект. Грят, надо какой-то шаблон скачать. А редактор говорит, что недоступно в оффлайн режиме. Что делать?
>>38031
Как ты написал это сюда из оффлайна? Значит не оффлайн. Качай.
Как ты написал это сюда из оффлайна? Значит не оффлайн. Качай.
>>38063
У деда профдеформация, он любой кодинг говном считает.
У деда профдеформация, он любой кодинг говном считает.
>>38714
Я изза этого все параметры метод называю с _. Хотя уже думаю с __ начинать, чтобы с неймингом неработающих приваток не пересекалось.
Я изза этого все параметры метод называю с _. Хотя уже думаю с __ начинать, чтобы с неймингом неработающих приваток не пересекалось.
>>38744
Прочерк это не приватки, это - неиспользуемое, оно может как быть приватным, так и просто неиспользуемым.
> неймингом неработающих приваток
Прочерк это не приватки, это - неиспользуемое, оно может как быть приватным, так и просто неиспользуемым.
416 Кб, 919x919Почему говорят что двери пиздец как сложно? У меня в игре на годоте есть 3 типа дверей - открываются по действию, по ключу и автоматом (если их толкнуть физикой). Я открывающимися дверями могу и другие физические объекты пинать. Все три реализации дались легко, теперь сидят-работают и проблем не доставляют. Это рофел такой?
>>38919
1)Всякие преколы, как в стенли парабл, где игроки научились выбегать из двери обратно раньше, чем она закроется. (Ломая этим игру)
2) Возможные баги физики
3) Унылость реалистичного открывания двери.
Просто накидал то, что пришло в голову. Может быть полной хуйней
1)Всякие преколы, как в стенли парабл, где игроки научились выбегать из двери обратно раньше, чем она закроется. (Ломая этим игру)
2) Возможные баги физики
3) Унылость реалистичного открывания двери.
Просто накидал то, что пришло в голову. Может быть полной хуйней
>>38919
Это просто мем такой геймдевовский.
Учи мемы, чтобы не быть баттхёртом.
https://en.wikipedia.org/wiki/Door_problem
Это просто мем такой геймдевовский.
Учи мемы, чтобы не быть баттхёртом.
https://en.wikipedia.org/wiki/Door_problem
>>38925
Реально сложной натурой задачи!
С другой стороны, мои вопросы отпали когда:
Бедняжка некая Лиз Ингланд, унижена дверями в собственной игре.
>summarizes the contrast between the perceived simplicity of implementing a trivial feature and the actual difficult nature of the task that becomes more apparent in a development process.
Реально сложной натурой задачи!
С другой стороны, мои вопросы отпали когда:
>The term was coined in 2014 by Liz England
Бедняжка некая Лиз Ингланд, унижена дверями в собственной игре.
>>38919
Туториал в А наравне с шейдерами и физикой тебя не смущает? Двери какой-то древний мем.
Туториал в А наравне с шейдерами и физикой тебя не смущает? Двери какой-то древний мем.
>>38929
Это ты сейчас такой молодой и шутливый, а если когда-нибудь релизнешь игру и она окажется популярна за пределами твоего шестого /b/ класса, то может ВНЕЗАПНО оказаться, что твои двери - говно.
>>38919
ТЕБЕ проблем не доставляют. А игроку? Игрока нужно представлять как импульсивного, вспыльчивого, умственно неполноценного, слепоглухонемого младенца с ожирением смертельной стадии, диким тремором всех конечностей-культяпок и самодельным карманным калькулятором вместо компьютера. И тестировать игру, рассчитывая что этот игрок ОБЯЗАН пройти всю игру от начала до конца без перезапусков, загрузок сохранения, патчей, модов, техподдержки...
Скажем, сможет ли игрок с первого взгляда понять, что эту конкретную дверь нужно ТОЛКНУТЬ, а не просто нажать кнопку? А сможет ли игрок понять, что дверь нужно открыть ключом, прежде чем её можно будет толкнуть? А сможет ли игрок найти ключ, не потеряв уверенность, что дверь реально возможно открыть и не злая шутка разработчика? А если игрок застрянет между дверью и стеной? А если что-то важное окажется случайно спрятанным или застрявшим за уже открытой дверью? А если игрок закроет за собой дверь, выбросив единственный ключ снаружи или через окно, в которое персонаж не пролезает, и даже не узнает об этом? А если игрок всё-таки подумает, что эта дверь - декоративная и не открывается, как бывает в большинстве популярных игр? А если игрок подумает, что что-то является дверью, что дверью не является, и будет несколько часов долбиться в это, тщетно пытаясь открыть? А если игрок попытается кинуть в "физическую" дверь то, что "физическим" технически не является, и разочаруется? А если монстр будет бежать в дверь с одной стороны, пока игрок пытается открыть её с другой стороны? А если игрок взорвал бомбу возле двери, и взрывная волна сдвинула шкаф внутри комнаты, заблокировав вход в комнату, куда игроку нужно пройти по сюжету? А если игрок убил монстра возле двери, а механика переноски физических трупов отсутствует или неизвестна игроку? А если у игрока компьютер слабый и физический движок не сможет правильно просчитать физику двери? А если у него какие-то особенные ошибки с плавающей точкой? А если эта дверь будет находиться за несколько километров от центра мира? А если игрок попытается заехать в дверь на мотоцикле, но по сюжету ему нужно быть пешком? А если дверь окажется на физическом корабле во время шторма? А если игрок разгонится как можно сильнее и пролетит сквозь дверь, которую он ещё не открыл ключом? А если игрок использует какую-то механику, воздействующую на все физические объекты, но ломающую физику подвешенных объектов? А если игрок заберётся на дверь? А если игрок каким-то образом сможет оторвать дверь? А если игрок засунет оторванную дверь в дверной проём другой двери? А если игрок не сможет оторвать дверь и расстроится?
Можно найти ещё тысячи причин, почему что-то может пойти не так с дверями. Но дело не дверях. Двери - это просто мем. В реальности любая часть игры создаёт подобную лавину проблем, хотя в самом начале тебе может показаться, что проблем никаких нет, если твой код состоит из пары строк и не вызывает кучи ошибок в консоли движка.
>Бедняжка
Это ты сейчас такой молодой и шутливый, а если когда-нибудь релизнешь игру и она окажется популярна за пределами твоего шестого /b/ класса, то может ВНЕЗАПНО оказаться, что твои двери - говно.
>>38919
>есть 3 типа дверей
>проблем не доставляют
ТЕБЕ проблем не доставляют. А игроку? Игрока нужно представлять как импульсивного, вспыльчивого, умственно неполноценного, слепоглухонемого младенца с ожирением смертельной стадии, диким тремором всех конечностей-культяпок и самодельным карманным калькулятором вместо компьютера. И тестировать игру, рассчитывая что этот игрок ОБЯЗАН пройти всю игру от начала до конца без перезапусков, загрузок сохранения, патчей, модов, техподдержки...
Скажем, сможет ли игрок с первого взгляда понять, что эту конкретную дверь нужно ТОЛКНУТЬ, а не просто нажать кнопку? А сможет ли игрок понять, что дверь нужно открыть ключом, прежде чем её можно будет толкнуть? А сможет ли игрок найти ключ, не потеряв уверенность, что дверь реально возможно открыть и не злая шутка разработчика? А если игрок застрянет между дверью и стеной? А если что-то важное окажется случайно спрятанным или застрявшим за уже открытой дверью? А если игрок закроет за собой дверь, выбросив единственный ключ снаружи или через окно, в которое персонаж не пролезает, и даже не узнает об этом? А если игрок всё-таки подумает, что эта дверь - декоративная и не открывается, как бывает в большинстве популярных игр? А если игрок подумает, что что-то является дверью, что дверью не является, и будет несколько часов долбиться в это, тщетно пытаясь открыть? А если игрок попытается кинуть в "физическую" дверь то, что "физическим" технически не является, и разочаруется? А если монстр будет бежать в дверь с одной стороны, пока игрок пытается открыть её с другой стороны? А если игрок взорвал бомбу возле двери, и взрывная волна сдвинула шкаф внутри комнаты, заблокировав вход в комнату, куда игроку нужно пройти по сюжету? А если игрок убил монстра возле двери, а механика переноски физических трупов отсутствует или неизвестна игроку? А если у игрока компьютер слабый и физический движок не сможет правильно просчитать физику двери? А если у него какие-то особенные ошибки с плавающей точкой? А если эта дверь будет находиться за несколько километров от центра мира? А если игрок попытается заехать в дверь на мотоцикле, но по сюжету ему нужно быть пешком? А если дверь окажется на физическом корабле во время шторма? А если игрок разгонится как можно сильнее и пролетит сквозь дверь, которую он ещё не открыл ключом? А если игрок использует какую-то механику, воздействующую на все физические объекты, но ломающую физику подвешенных объектов? А если игрок заберётся на дверь? А если игрок каким-то образом сможет оторвать дверь? А если игрок засунет оторванную дверь в дверной проём другой двери? А если игрок не сможет оторвать дверь и расстроится?
Можно найти ещё тысячи причин, почему что-то может пойти не так с дверями. Но дело не дверях. Двери - это просто мем. В реальности любая часть игры создаёт подобную лавину проблем, хотя в самом начале тебе может показаться, что проблем никаких нет, если твой код состоит из пары строк и не вызывает кучи ошибок в консоли движка.
>>38929
Это ты сейчас такой молодой и шутливый, а если когда-нибудь релизнешь игру и она окажется популярна за пределами твоего шестого /b/ класса, то может ВНЕЗАПНО оказаться, что твои двери - говно.
>>38919
ТЕБЕ проблем не доставляют. А игроку? Игрока нужно представлять как импульсивного, вспыльчивого, умственно неполноценного, слепоглухонемого младенца с ожирением смертельной стадии, диким тремором всех конечностей-культяпок и самодельным карманным калькулятором вместо компьютера. И тестировать игру, рассчитывая что этот игрок ОБЯЗАН пройти всю игру от начала до конца без перезапусков, загрузок сохранения, патчей, модов, техподдержки...
Скажем, сможет ли игрок с первого взгляда понять, что эту конкретную дверь нужно ТОЛКНУТЬ, а не просто нажать кнопку? А сможет ли игрок понять, что дверь нужно открыть ключом, прежде чем её можно будет толкнуть? А сможет ли игрок найти ключ, не потеряв уверенность, что дверь реально возможно открыть и не злая шутка разработчика? А если игрок застрянет между дверью и стеной? А если что-то важное окажется случайно спрятанным или застрявшим за уже открытой дверью? А если игрок закроет за собой дверь, выбросив единственный ключ снаружи или через окно, в которое персонаж не пролезает, и даже не узнает об этом? А если игрок всё-таки подумает, что эта дверь - декоративная и не открывается, как бывает в большинстве популярных игр? А если игрок подумает, что что-то является дверью, что дверью не является, и будет несколько часов долбиться в это, тщетно пытаясь открыть? А если игрок попытается кинуть в "физическую" дверь то, что "физическим" технически не является, и разочаруется? А если монстр будет бежать в дверь с одной стороны, пока игрок пытается открыть её с другой стороны? А если игрок взорвал бомбу возле двери, и взрывная волна сдвинула шкаф внутри комнаты, заблокировав вход в комнату, куда игроку нужно пройти по сюжету? А если игрок убил монстра возле двери, а механика переноски физических трупов отсутствует или неизвестна игроку? А если у игрока компьютер слабый и физический движок не сможет правильно просчитать физику двери? А если у него какие-то особенные ошибки с плавающей точкой? А если эта дверь будет находиться за несколько километров от центра мира? А если игрок попытается заехать в дверь на мотоцикле, но по сюжету ему нужно быть пешком? А если дверь окажется на физическом корабле во время шторма? А если игрок разгонится как можно сильнее и пролетит сквозь дверь, которую он ещё не открыл ключом? А если игрок использует какую-то механику, воздействующую на все физические объекты, но ломающую физику подвешенных объектов? А если игрок заберётся на дверь? А если игрок каким-то образом сможет оторвать дверь? А если игрок засунет оторванную дверь в дверной проём другой двери? А если игрок не сможет оторвать дверь и расстроится?
Можно найти ещё тысячи причин, почему что-то может пойти не так с дверями. Но дело не дверях. Двери - это просто мем. В реальности любая часть игры создаёт подобную лавину проблем, хотя в самом начале тебе может показаться, что проблем никаких нет, если твой код состоит из пары строк и не вызывает кучи ошибок в консоли движка.
>Бедняжка
Это ты сейчас такой молодой и шутливый, а если когда-нибудь релизнешь игру и она окажется популярна за пределами твоего шестого /b/ класса, то может ВНЕЗАПНО оказаться, что твои двери - говно.
>>38919
>есть 3 типа дверей
>проблем не доставляют
ТЕБЕ проблем не доставляют. А игроку? Игрока нужно представлять как импульсивного, вспыльчивого, умственно неполноценного, слепоглухонемого младенца с ожирением смертельной стадии, диким тремором всех конечностей-культяпок и самодельным карманным калькулятором вместо компьютера. И тестировать игру, рассчитывая что этот игрок ОБЯЗАН пройти всю игру от начала до конца без перезапусков, загрузок сохранения, патчей, модов, техподдержки...
Скажем, сможет ли игрок с первого взгляда понять, что эту конкретную дверь нужно ТОЛКНУТЬ, а не просто нажать кнопку? А сможет ли игрок понять, что дверь нужно открыть ключом, прежде чем её можно будет толкнуть? А сможет ли игрок найти ключ, не потеряв уверенность, что дверь реально возможно открыть и не злая шутка разработчика? А если игрок застрянет между дверью и стеной? А если что-то важное окажется случайно спрятанным или застрявшим за уже открытой дверью? А если игрок закроет за собой дверь, выбросив единственный ключ снаружи или через окно, в которое персонаж не пролезает, и даже не узнает об этом? А если игрок всё-таки подумает, что эта дверь - декоративная и не открывается, как бывает в большинстве популярных игр? А если игрок подумает, что что-то является дверью, что дверью не является, и будет несколько часов долбиться в это, тщетно пытаясь открыть? А если игрок попытается кинуть в "физическую" дверь то, что "физическим" технически не является, и разочаруется? А если монстр будет бежать в дверь с одной стороны, пока игрок пытается открыть её с другой стороны? А если игрок взорвал бомбу возле двери, и взрывная волна сдвинула шкаф внутри комнаты, заблокировав вход в комнату, куда игроку нужно пройти по сюжету? А если игрок убил монстра возле двери, а механика переноски физических трупов отсутствует или неизвестна игроку? А если у игрока компьютер слабый и физический движок не сможет правильно просчитать физику двери? А если у него какие-то особенные ошибки с плавающей точкой? А если эта дверь будет находиться за несколько километров от центра мира? А если игрок попытается заехать в дверь на мотоцикле, но по сюжету ему нужно быть пешком? А если дверь окажется на физическом корабле во время шторма? А если игрок разгонится как можно сильнее и пролетит сквозь дверь, которую он ещё не открыл ключом? А если игрок использует какую-то механику, воздействующую на все физические объекты, но ломающую физику подвешенных объектов? А если игрок заберётся на дверь? А если игрок каким-то образом сможет оторвать дверь? А если игрок засунет оторванную дверь в дверной проём другой двери? А если игрок не сможет оторвать дверь и расстроится?
Можно найти ещё тысячи причин, почему что-то может пойти не так с дверями. Но дело не дверях. Двери - это просто мем. В реальности любая часть игры создаёт подобную лавину проблем, хотя в самом начале тебе может показаться, что проблем никаких нет, если твой код состоит из пары строк и не вызывает кучи ошибок в консоли движка.
>>38968
Мои двери не говно!
Мои двери не говно!
>>38919
где лестницы???
где лестницы???
>>38013
Вариант 1: добавить TSCN-сцену в качестве тайла в тайлсете (новая фича).
Вариант 2:
- добавить второй, отдельный слой карты, чисто под треугольники;
- назначить треугольникам коллизию, но на другой физический слой;
- дать сцене игрока Area2D, которая этот другой слой будет детектить;
- детектить контакт между этой Area игрока и слоём треугольников.
Мне кажется, второй вариант должен быть производительнее.
>>37956
Лучше - никак. Старайся делать только локальные переменные.
С каждой новой глобальной ты усложняешь себе жизнь в будущем...
>>38031
Ты в настройках Godot, видимо, выбрал "оффлайн-режим".
Можешь скачать его сам, через браузер: https://godotengine.org/download/
>>38744
Если не нужен этот warning, его можно в настройках проекта выключить.
>>37902
Если смотреть популярное, там всё одинаковое - гоблины, орки, эльфы, и т.д.
Открываешь https://tvtropes.org/ и собираешь в свою игру всё интересное.
>должен быть отдельной сценой и Area2D
>хочу рисовать ими через tilemap
Вариант 1: добавить TSCN-сцену в качестве тайла в тайлсете (новая фича).
Вариант 2:
- добавить второй, отдельный слой карты, чисто под треугольники;
- назначить треугольникам коллизию, но на другой физический слой;
- дать сцене игрока Area2D, которая этот другой слой будет детектить;
- детектить контакт между этой Area игрока и слоём треугольников.
Мне кажется, второй вариант должен быть производительнее.
>>37956
>объявлять глобальные перемены
Лучше - никак. Старайся делать только локальные переменные.
С каждой новой глобальной ты усложняешь себе жизнь в будущем...
>>38031
>недоступно в оффлайн режиме
Ты в настройках Godot, видимо, выбрал "оффлайн-режим".
>надо какой-то шаблон скачать
Можешь скачать его сам, через браузер: https://godotengine.org/download/
>Export templates
>Used to export your games to all supported platforms
>>38744
>Я изза этого все параметры метод называю с _.
Если не нужен этот warning, его можно в настройках проекта выключить.
>>37902
>А свои сеттинги это сложно. Ворлдбилдинг там, персонажи запоминающиеся
Если смотреть популярное, там всё одинаковое - гоблины, орки, эльфы, и т.д.
Открываешь https://tvtropes.org/ и собираешь в свою игру всё интересное.
>>38013
Вариант 1: добавить TSCN-сцену в качестве тайла в тайлсете (новая фича).
Вариант 2:
- добавить второй, отдельный слой карты, чисто под треугольники;
- назначить треугольникам коллизию, но на другой физический слой;
- дать сцене игрока Area2D, которая этот другой слой будет детектить;
- детектить контакт между этой Area игрока и слоём треугольников.
Мне кажется, второй вариант должен быть производительнее.
>>37956
Лучше - никак. Старайся делать только локальные переменные.
С каждой новой глобальной ты усложняешь себе жизнь в будущем...
>>38031
Ты в настройках Godot, видимо, выбрал "оффлайн-режим".
Можешь скачать его сам, через браузер: https://godotengine.org/download/
>>38744
Если не нужен этот warning, его можно в настройках проекта выключить.
>>37902
Если смотреть популярное, там всё одинаковое - гоблины, орки, эльфы, и т.д.
Открываешь https://tvtropes.org/ и собираешь в свою игру всё интересное.
>должен быть отдельной сценой и Area2D
>хочу рисовать ими через tilemap
Вариант 1: добавить TSCN-сцену в качестве тайла в тайлсете (новая фича).
Вариант 2:
- добавить второй, отдельный слой карты, чисто под треугольники;
- назначить треугольникам коллизию, но на другой физический слой;
- дать сцене игрока Area2D, которая этот другой слой будет детектить;
- детектить контакт между этой Area игрока и слоём треугольников.
Мне кажется, второй вариант должен быть производительнее.
>>37956
>объявлять глобальные перемены
Лучше - никак. Старайся делать только локальные переменные.
С каждой новой глобальной ты усложняешь себе жизнь в будущем...
>>38031
>недоступно в оффлайн режиме
Ты в настройках Godot, видимо, выбрал "оффлайн-режим".
>надо какой-то шаблон скачать
Можешь скачать его сам, через браузер: https://godotengine.org/download/
>Export templates
>Used to export your games to all supported platforms
>>38744
>Я изза этого все параметры метод называю с _.
Если не нужен этот warning, его можно в настройках проекта выключить.
>>37902
>А свои сеттинги это сложно. Ворлдбилдинг там, персонажи запоминающиеся
Если смотреть популярное, там всё одинаковое - гоблины, орки, эльфы, и т.д.
Открываешь https://tvtropes.org/ и собираешь в свою игру всё интересное.
671 Кб, mp4,1280x720, 0:12
>>30839 (OP)
Накидал по-быстрому, чисто CSG и AnimationPlayer.
Планирую позже добавить дымок и ещё что-то...
Накидал по-быстрому, чисто CSG и AnimationPlayer.
Планирую позже добавить дымок и ещё что-то...
>>37976
Во-первых, большинство застреваний у персонажей происходят из-за коллизий. Что ты используешь для коллизий? Не используй формы с углами - старайся использовать только сферы (SphereShape3D) и капсулы (CapsuleShape3D) - они позволяют избежать большинства застреваний. Также можно попробовать добавить форму луча (SeparationRayShape3D), она позволяет игнорировать мелкие неровности на земле. Капсула или сфера, сидящая на достаточно длинном луче, будет контактировать только со стенами и другими такими же капсулами/сферами других персонажей.
А что используешь для движения? Метод move_and_slide() практически нигде не может застрять, и чтобы два персонажа с этим методом столкнулись, они должны идти строго друг на друга - в любом другом случае они плавно проскользнут мимо друг друга. Персонажи со сферами или капсулами практически неспособны толкать друг друга из-за того, что они неизбежно проскальзывают мимо.
Жёсткие столкновения будут только если у тебя буквально толпа из десятков человек в одном месте, но в таких случаях нужно использовать совсем другие оптимизации, рассуждая не о персонажах, а о группах персонажей или толпе в целом. Другого способа сделать условную толпу зомби производительно нет. В случае 2-3 персонажей, проблем от столкновений между ними быть не должно.
Во-вторых, система навигации в игровом движке по-английски называется "path finding" - т.е. "поиск пути". Представь себе GPS-навигатор: он показывает тебе весьма грубую линию вдоль дорог на карте города, но всё остальное ты должен сделать своими мозгами и ногами в зависимости от текущей обстановки. Поиск пути в игре может дать тебе набор точек до цели, но как двигаться к каждой из этих точек - решать тебе.
Рационально строить маршруты можно с помощью алгоритма AStar, раздавая разным нодам коэффициент проходимости, при этом нодой может быть абсолютно что угодно - в том числе места для паркура, трюки в воздухе и прочее подобное. Проще всего осмыслить это на 2D сетке. Если, скажем, движение через болото стоит 15 очков за клетку, а движение в обход болота займёт 5 клеток по цене 2 очка, AStar построит путь в обход болота. Но если ближайший обход болота будет 9 клеток, то AStar выберет путь через клетку болота, потому что (1 клетка x 15 = 15) < (9 клеток x 2 = 18).
Собственно, навмеши (navigation mesh) под капотом используют AStar. Суть навмешей в том, чтобы автоматически разделить проходимые зоны на полигоны, а затем построить путь через центры этих полигонов с помощью AStar, т.к. эти полигоны представляют из себя граф. Если твоя игра имеет некое нестандартное движение по сложной местности, стандартные навмеши тебе вряд ли сильно помогут. Но если ты генерируешь карту процедурно, то и навигационные точки расставить сможешь процедурно. При этом твои навигационные точки могут быть даже лучше того, что может предложить навмеш, т.к. никто не знает твою задумку в плане движения по карте лучше тебя.
Касательно паркура, рекомендую начать с игрового персонажа, который полностью подчиняется всем действиям игрока напрямую - управление на WASD как в шутерах. Научи этого персонажа карабкаться по стенам или выступам, перепрыгивать препятствия, делать трюки в воздухе и прочее подобное. Это даст тебе основу для NPC, потому что мозгам NPC нужно только выбирать правильное действие в конкретной ситуации. Логика выбора действия будет зависеть от информации на карте и/или рейкастов.
При этом размещать информацию прямо на карте (типа Area3D вокруг бревна, предлагающая NPC выбрать "крутой прыжок с кувырком" вместо "прыжок") должно быть производительнее и проще в реализации, чем делать сложную систему распознавания ситуации без информации на карте (т.е. анализировать форму и размер препятствия, ощупывая его множеством рейкастов и пытаясь отличить "бревно с сучками" от "бревно без сучков", чтобы сделать выбор между "крутой прыжок с кувырком" и "прыжок"). Опять же, процедурно налепить этих специальных маркеров будет не сложнее, чем сгенерировать базовую карту - достаточно добавить новый маркер "прыгни с кувырком" в сцену "бревно" (или "бревно с сучками"), которая у тебя уже как-то размещается на твоих процедурных картах - ничего кроме этого в генерации не изменится.
Также, хотя у тебя на скриншотах только капсулы, рекомендую заранее абстрагировать физику персонажей от их графического представления. Секрет 3D персонажей в том, что они изображают графически много всего, что физически в игре просто не существует. Физически у тебя движется только капсула, возможно, намного толще и выше видимой на экране модельки персонажа. А моделька регистрирует это движение капсулы и выбирает, какую анимацию ей нужно использовать, куда ставить ноги и т.п. В том же паркуре, например, физическая капсула может просто телепортироваться сквозь стену прямо перед ней, тогда как визуальная моделька персонажа будет несколько секунд проигрывать анимацию "карабкаюсь на стенку, переваливаюсь через стенку и приземляюсь с другой стороны". Хитбоксы, кстати, вообще отдельная от физики движения тема: они должны точно повторять форму и движение визуальной модели, но ни с чем не должны физически взаимодействовать - только регистрировать столкновение с другими хитбоксами.
Всё это сложно уложить в голове, т.к. в популярных играх мы обычно не видим никаких коллизий, и мозг воспринимает визуальную модельку на экране как первичное тело персонажа, тогда как в реальности она вторична и не соответствует реальной игровой физике. По этой же причине, работая с жёлтыми капсулами на твоих скриншотах, ты можешь испытывать ощущение "как-то оно неправильно двигается", хотя всё нормально. Вообще, игры строятся из иллюзий и обмана восприятия игрока, там редко бывают "честные симуляции".
Что мы имеем в итоге:
1. Поиск пути выбирает грубый, но проходимый набор точек маршрута из А в Б.
2. Физическая капсула движется по точкам, проскальзывая мелкие препятствия.
3. Визуальная моделька следует вслед за капсулой, правильно ставя ноги и т.д.
4. Карта сообщает персонажу, какие трюки можно использовать прямо сейчас.
5. Визуальная моделька проигрывает анимации трюков по запросу персонажа.
Если хочешь совсем без меток-триггеров, размещённых на карте, то придётся отказаться и от поиска пути в обычном для игр понимании. Технически ты можешь обвесить своего персонажа большим массивом рейкастов и отправлять данные с этого массива в нейросеть, которую можно тренировать обучением с подкреплением - то есть, если твой персонаж смог продвинуться чуть дальше по карте, нейросеть будет получать "награду" (плюс к значениям весов соединений между нейронами), а если персонаж не продвигается или отступает, нейросеть получает "наказание" (минус к весам). Также потребуется иногда принуждать нейронку выбирать необычные действия, иначе она застрянет на локальном оптимуме. Если массив рейкастов даёт достаточно информации для решения, достаточно крупная нейросеть рано или поздно научится проходить карты произвольной формы наиболее эффективным способом. Но помимо рейкастов (т.е. расстояния до препятствия) может потребоваться отправлять информацию о материалах, например, если у тебя движение через высокую траву медленнее движения по тропинке, или если на карте есть какие-то смертельные ловушки и т.п. При этом нужно понимать, что нейронка будет тренироваться очень долго и первое время будет ужасно тупой, а заранее определить наверняка, обучится она чему-то или нет, в общем случае невозможно.
Собственно, навмеши - это и есть "метки-триггеры", только в обобщённом смысле и для прямолинейного движения по относительно плоским поверхностям, которые можно разделить на полигоны. AStar - для движения по точкам в произвольном пространстве, хоть в четырёхмерном, но метки откуда-то должны изначально взяться. Нейросеть с рейкастами может ориентироваться в любом пространстве совсем без меток, но ей для этого потребуется долго обучаться на примерах правильного и неправильного движения.
Конечно же, ты можешь обвесить своих персонажей портянкой if elif elif elif else, но это будет сложно.
Как понимаешь, ждать чуда от новых версий движка в плане навигации персонажей бесполезно.
Во-первых, большинство застреваний у персонажей происходят из-за коллизий. Что ты используешь для коллизий? Не используй формы с углами - старайся использовать только сферы (SphereShape3D) и капсулы (CapsuleShape3D) - они позволяют избежать большинства застреваний. Также можно попробовать добавить форму луча (SeparationRayShape3D), она позволяет игнорировать мелкие неровности на земле. Капсула или сфера, сидящая на достаточно длинном луче, будет контактировать только со стенами и другими такими же капсулами/сферами других персонажей.
А что используешь для движения? Метод move_and_slide() практически нигде не может застрять, и чтобы два персонажа с этим методом столкнулись, они должны идти строго друг на друга - в любом другом случае они плавно проскользнут мимо друг друга. Персонажи со сферами или капсулами практически неспособны толкать друг друга из-за того, что они неизбежно проскальзывают мимо.
Жёсткие столкновения будут только если у тебя буквально толпа из десятков человек в одном месте, но в таких случаях нужно использовать совсем другие оптимизации, рассуждая не о персонажах, а о группах персонажей или толпе в целом. Другого способа сделать условную толпу зомби производительно нет. В случае 2-3 персонажей, проблем от столкновений между ними быть не должно.
Во-вторых, система навигации в игровом движке по-английски называется "path finding" - т.е. "поиск пути". Представь себе GPS-навигатор: он показывает тебе весьма грубую линию вдоль дорог на карте города, но всё остальное ты должен сделать своими мозгами и ногами в зависимости от текущей обстановки. Поиск пути в игре может дать тебе набор точек до цели, но как двигаться к каждой из этих точек - решать тебе.
Рационально строить маршруты можно с помощью алгоритма AStar, раздавая разным нодам коэффициент проходимости, при этом нодой может быть абсолютно что угодно - в том числе места для паркура, трюки в воздухе и прочее подобное. Проще всего осмыслить это на 2D сетке. Если, скажем, движение через болото стоит 15 очков за клетку, а движение в обход болота займёт 5 клеток по цене 2 очка, AStar построит путь в обход болота. Но если ближайший обход болота будет 9 клеток, то AStar выберет путь через клетку болота, потому что (1 клетка x 15 = 15) < (9 клеток x 2 = 18).
Собственно, навмеши (navigation mesh) под капотом используют AStar. Суть навмешей в том, чтобы автоматически разделить проходимые зоны на полигоны, а затем построить путь через центры этих полигонов с помощью AStar, т.к. эти полигоны представляют из себя граф. Если твоя игра имеет некое нестандартное движение по сложной местности, стандартные навмеши тебе вряд ли сильно помогут. Но если ты генерируешь карту процедурно, то и навигационные точки расставить сможешь процедурно. При этом твои навигационные точки могут быть даже лучше того, что может предложить навмеш, т.к. никто не знает твою задумку в плане движения по карте лучше тебя.
Касательно паркура, рекомендую начать с игрового персонажа, который полностью подчиняется всем действиям игрока напрямую - управление на WASD как в шутерах. Научи этого персонажа карабкаться по стенам или выступам, перепрыгивать препятствия, делать трюки в воздухе и прочее подобное. Это даст тебе основу для NPC, потому что мозгам NPC нужно только выбирать правильное действие в конкретной ситуации. Логика выбора действия будет зависеть от информации на карте и/или рейкастов.
При этом размещать информацию прямо на карте (типа Area3D вокруг бревна, предлагающая NPC выбрать "крутой прыжок с кувырком" вместо "прыжок") должно быть производительнее и проще в реализации, чем делать сложную систему распознавания ситуации без информации на карте (т.е. анализировать форму и размер препятствия, ощупывая его множеством рейкастов и пытаясь отличить "бревно с сучками" от "бревно без сучков", чтобы сделать выбор между "крутой прыжок с кувырком" и "прыжок"). Опять же, процедурно налепить этих специальных маркеров будет не сложнее, чем сгенерировать базовую карту - достаточно добавить новый маркер "прыгни с кувырком" в сцену "бревно" (или "бревно с сучками"), которая у тебя уже как-то размещается на твоих процедурных картах - ничего кроме этого в генерации не изменится.
Также, хотя у тебя на скриншотах только капсулы, рекомендую заранее абстрагировать физику персонажей от их графического представления. Секрет 3D персонажей в том, что они изображают графически много всего, что физически в игре просто не существует. Физически у тебя движется только капсула, возможно, намного толще и выше видимой на экране модельки персонажа. А моделька регистрирует это движение капсулы и выбирает, какую анимацию ей нужно использовать, куда ставить ноги и т.п. В том же паркуре, например, физическая капсула может просто телепортироваться сквозь стену прямо перед ней, тогда как визуальная моделька персонажа будет несколько секунд проигрывать анимацию "карабкаюсь на стенку, переваливаюсь через стенку и приземляюсь с другой стороны". Хитбоксы, кстати, вообще отдельная от физики движения тема: они должны точно повторять форму и движение визуальной модели, но ни с чем не должны физически взаимодействовать - только регистрировать столкновение с другими хитбоксами.
Всё это сложно уложить в голове, т.к. в популярных играх мы обычно не видим никаких коллизий, и мозг воспринимает визуальную модельку на экране как первичное тело персонажа, тогда как в реальности она вторична и не соответствует реальной игровой физике. По этой же причине, работая с жёлтыми капсулами на твоих скриншотах, ты можешь испытывать ощущение "как-то оно неправильно двигается", хотя всё нормально. Вообще, игры строятся из иллюзий и обмана восприятия игрока, там редко бывают "честные симуляции".
Что мы имеем в итоге:
1. Поиск пути выбирает грубый, но проходимый набор точек маршрута из А в Б.
2. Физическая капсула движется по точкам, проскальзывая мелкие препятствия.
3. Визуальная моделька следует вслед за капсулой, правильно ставя ноги и т.д.
4. Карта сообщает персонажу, какие трюки можно использовать прямо сейчас.
5. Визуальная моделька проигрывает анимации трюков по запросу персонажа.
Если хочешь совсем без меток-триггеров, размещённых на карте, то придётся отказаться и от поиска пути в обычном для игр понимании. Технически ты можешь обвесить своего персонажа большим массивом рейкастов и отправлять данные с этого массива в нейросеть, которую можно тренировать обучением с подкреплением - то есть, если твой персонаж смог продвинуться чуть дальше по карте, нейросеть будет получать "награду" (плюс к значениям весов соединений между нейронами), а если персонаж не продвигается или отступает, нейросеть получает "наказание" (минус к весам). Также потребуется иногда принуждать нейронку выбирать необычные действия, иначе она застрянет на локальном оптимуме. Если массив рейкастов даёт достаточно информации для решения, достаточно крупная нейросеть рано или поздно научится проходить карты произвольной формы наиболее эффективным способом. Но помимо рейкастов (т.е. расстояния до препятствия) может потребоваться отправлять информацию о материалах, например, если у тебя движение через высокую траву медленнее движения по тропинке, или если на карте есть какие-то смертельные ловушки и т.п. При этом нужно понимать, что нейронка будет тренироваться очень долго и первое время будет ужасно тупой, а заранее определить наверняка, обучится она чему-то или нет, в общем случае невозможно.
Собственно, навмеши - это и есть "метки-триггеры", только в обобщённом смысле и для прямолинейного движения по относительно плоским поверхностям, которые можно разделить на полигоны. AStar - для движения по точкам в произвольном пространстве, хоть в четырёхмерном, но метки откуда-то должны изначально взяться. Нейросеть с рейкастами может ориентироваться в любом пространстве совсем без меток, но ей для этого потребуется долго обучаться на примерах правильного и неправильного движения.
Конечно же, ты можешь обвесить своих персонажей портянкой if elif elif elif else, но это будет сложно.
Как понимаешь, ждать чуда от новых версий движка в плане навигации персонажей бесполезно.
>>37976
Во-первых, большинство застреваний у персонажей происходят из-за коллизий. Что ты используешь для коллизий? Не используй формы с углами - старайся использовать только сферы (SphereShape3D) и капсулы (CapsuleShape3D) - они позволяют избежать большинства застреваний. Также можно попробовать добавить форму луча (SeparationRayShape3D), она позволяет игнорировать мелкие неровности на земле. Капсула или сфера, сидящая на достаточно длинном луче, будет контактировать только со стенами и другими такими же капсулами/сферами других персонажей.
А что используешь для движения? Метод move_and_slide() практически нигде не может застрять, и чтобы два персонажа с этим методом столкнулись, они должны идти строго друг на друга - в любом другом случае они плавно проскользнут мимо друг друга. Персонажи со сферами или капсулами практически неспособны толкать друг друга из-за того, что они неизбежно проскальзывают мимо.
Жёсткие столкновения будут только если у тебя буквально толпа из десятков человек в одном месте, но в таких случаях нужно использовать совсем другие оптимизации, рассуждая не о персонажах, а о группах персонажей или толпе в целом. Другого способа сделать условную толпу зомби производительно нет. В случае 2-3 персонажей, проблем от столкновений между ними быть не должно.
Во-вторых, система навигации в игровом движке по-английски называется "path finding" - т.е. "поиск пути". Представь себе GPS-навигатор: он показывает тебе весьма грубую линию вдоль дорог на карте города, но всё остальное ты должен сделать своими мозгами и ногами в зависимости от текущей обстановки. Поиск пути в игре может дать тебе набор точек до цели, но как двигаться к каждой из этих точек - решать тебе.
Рационально строить маршруты можно с помощью алгоритма AStar, раздавая разным нодам коэффициент проходимости, при этом нодой может быть абсолютно что угодно - в том числе места для паркура, трюки в воздухе и прочее подобное. Проще всего осмыслить это на 2D сетке. Если, скажем, движение через болото стоит 15 очков за клетку, а движение в обход болота займёт 5 клеток по цене 2 очка, AStar построит путь в обход болота. Но если ближайший обход болота будет 9 клеток, то AStar выберет путь через клетку болота, потому что (1 клетка x 15 = 15) < (9 клеток x 2 = 18).
Собственно, навмеши (navigation mesh) под капотом используют AStar. Суть навмешей в том, чтобы автоматически разделить проходимые зоны на полигоны, а затем построить путь через центры этих полигонов с помощью AStar, т.к. эти полигоны представляют из себя граф. Если твоя игра имеет некое нестандартное движение по сложной местности, стандартные навмеши тебе вряд ли сильно помогут. Но если ты генерируешь карту процедурно, то и навигационные точки расставить сможешь процедурно. При этом твои навигационные точки могут быть даже лучше того, что может предложить навмеш, т.к. никто не знает твою задумку в плане движения по карте лучше тебя.
Касательно паркура, рекомендую начать с игрового персонажа, который полностью подчиняется всем действиям игрока напрямую - управление на WASD как в шутерах. Научи этого персонажа карабкаться по стенам или выступам, перепрыгивать препятствия, делать трюки в воздухе и прочее подобное. Это даст тебе основу для NPC, потому что мозгам NPC нужно только выбирать правильное действие в конкретной ситуации. Логика выбора действия будет зависеть от информации на карте и/или рейкастов.
При этом размещать информацию прямо на карте (типа Area3D вокруг бревна, предлагающая NPC выбрать "крутой прыжок с кувырком" вместо "прыжок") должно быть производительнее и проще в реализации, чем делать сложную систему распознавания ситуации без информации на карте (т.е. анализировать форму и размер препятствия, ощупывая его множеством рейкастов и пытаясь отличить "бревно с сучками" от "бревно без сучков", чтобы сделать выбор между "крутой прыжок с кувырком" и "прыжок"). Опять же, процедурно налепить этих специальных маркеров будет не сложнее, чем сгенерировать базовую карту - достаточно добавить новый маркер "прыгни с кувырком" в сцену "бревно" (или "бревно с сучками"), которая у тебя уже как-то размещается на твоих процедурных картах - ничего кроме этого в генерации не изменится.
Также, хотя у тебя на скриншотах только капсулы, рекомендую заранее абстрагировать физику персонажей от их графического представления. Секрет 3D персонажей в том, что они изображают графически много всего, что физически в игре просто не существует. Физически у тебя движется только капсула, возможно, намного толще и выше видимой на экране модельки персонажа. А моделька регистрирует это движение капсулы и выбирает, какую анимацию ей нужно использовать, куда ставить ноги и т.п. В том же паркуре, например, физическая капсула может просто телепортироваться сквозь стену прямо перед ней, тогда как визуальная моделька персонажа будет несколько секунд проигрывать анимацию "карабкаюсь на стенку, переваливаюсь через стенку и приземляюсь с другой стороны". Хитбоксы, кстати, вообще отдельная от физики движения тема: они должны точно повторять форму и движение визуальной модели, но ни с чем не должны физически взаимодействовать - только регистрировать столкновение с другими хитбоксами.
Всё это сложно уложить в голове, т.к. в популярных играх мы обычно не видим никаких коллизий, и мозг воспринимает визуальную модельку на экране как первичное тело персонажа, тогда как в реальности она вторична и не соответствует реальной игровой физике. По этой же причине, работая с жёлтыми капсулами на твоих скриншотах, ты можешь испытывать ощущение "как-то оно неправильно двигается", хотя всё нормально. Вообще, игры строятся из иллюзий и обмана восприятия игрока, там редко бывают "честные симуляции".
Что мы имеем в итоге:
1. Поиск пути выбирает грубый, но проходимый набор точек маршрута из А в Б.
2. Физическая капсула движется по точкам, проскальзывая мелкие препятствия.
3. Визуальная моделька следует вслед за капсулой, правильно ставя ноги и т.д.
4. Карта сообщает персонажу, какие трюки можно использовать прямо сейчас.
5. Визуальная моделька проигрывает анимации трюков по запросу персонажа.
Если хочешь совсем без меток-триггеров, размещённых на карте, то придётся отказаться и от поиска пути в обычном для игр понимании. Технически ты можешь обвесить своего персонажа большим массивом рейкастов и отправлять данные с этого массива в нейросеть, которую можно тренировать обучением с подкреплением - то есть, если твой персонаж смог продвинуться чуть дальше по карте, нейросеть будет получать "награду" (плюс к значениям весов соединений между нейронами), а если персонаж не продвигается или отступает, нейросеть получает "наказание" (минус к весам). Также потребуется иногда принуждать нейронку выбирать необычные действия, иначе она застрянет на локальном оптимуме. Если массив рейкастов даёт достаточно информации для решения, достаточно крупная нейросеть рано или поздно научится проходить карты произвольной формы наиболее эффективным способом. Но помимо рейкастов (т.е. расстояния до препятствия) может потребоваться отправлять информацию о материалах, например, если у тебя движение через высокую траву медленнее движения по тропинке, или если на карте есть какие-то смертельные ловушки и т.п. При этом нужно понимать, что нейронка будет тренироваться очень долго и первое время будет ужасно тупой, а заранее определить наверняка, обучится она чему-то или нет, в общем случае невозможно.
Собственно, навмеши - это и есть "метки-триггеры", только в обобщённом смысле и для прямолинейного движения по относительно плоским поверхностям, которые можно разделить на полигоны. AStar - для движения по точкам в произвольном пространстве, хоть в четырёхмерном, но метки откуда-то должны изначально взяться. Нейросеть с рейкастами может ориентироваться в любом пространстве совсем без меток, но ей для этого потребуется долго обучаться на примерах правильного и неправильного движения.
Конечно же, ты можешь обвесить своих персонажей портянкой if elif elif elif else, но это будет сложно.
Как понимаешь, ждать чуда от новых версий движка в плане навигации персонажей бесполезно.
Во-первых, большинство застреваний у персонажей происходят из-за коллизий. Что ты используешь для коллизий? Не используй формы с углами - старайся использовать только сферы (SphereShape3D) и капсулы (CapsuleShape3D) - они позволяют избежать большинства застреваний. Также можно попробовать добавить форму луча (SeparationRayShape3D), она позволяет игнорировать мелкие неровности на земле. Капсула или сфера, сидящая на достаточно длинном луче, будет контактировать только со стенами и другими такими же капсулами/сферами других персонажей.
А что используешь для движения? Метод move_and_slide() практически нигде не может застрять, и чтобы два персонажа с этим методом столкнулись, они должны идти строго друг на друга - в любом другом случае они плавно проскользнут мимо друг друга. Персонажи со сферами или капсулами практически неспособны толкать друг друга из-за того, что они неизбежно проскальзывают мимо.
Жёсткие столкновения будут только если у тебя буквально толпа из десятков человек в одном месте, но в таких случаях нужно использовать совсем другие оптимизации, рассуждая не о персонажах, а о группах персонажей или толпе в целом. Другого способа сделать условную толпу зомби производительно нет. В случае 2-3 персонажей, проблем от столкновений между ними быть не должно.
Во-вторых, система навигации в игровом движке по-английски называется "path finding" - т.е. "поиск пути". Представь себе GPS-навигатор: он показывает тебе весьма грубую линию вдоль дорог на карте города, но всё остальное ты должен сделать своими мозгами и ногами в зависимости от текущей обстановки. Поиск пути в игре может дать тебе набор точек до цели, но как двигаться к каждой из этих точек - решать тебе.
Рационально строить маршруты можно с помощью алгоритма AStar, раздавая разным нодам коэффициент проходимости, при этом нодой может быть абсолютно что угодно - в том числе места для паркура, трюки в воздухе и прочее подобное. Проще всего осмыслить это на 2D сетке. Если, скажем, движение через болото стоит 15 очков за клетку, а движение в обход болота займёт 5 клеток по цене 2 очка, AStar построит путь в обход болота. Но если ближайший обход болота будет 9 клеток, то AStar выберет путь через клетку болота, потому что (1 клетка x 15 = 15) < (9 клеток x 2 = 18).
Собственно, навмеши (navigation mesh) под капотом используют AStar. Суть навмешей в том, чтобы автоматически разделить проходимые зоны на полигоны, а затем построить путь через центры этих полигонов с помощью AStar, т.к. эти полигоны представляют из себя граф. Если твоя игра имеет некое нестандартное движение по сложной местности, стандартные навмеши тебе вряд ли сильно помогут. Но если ты генерируешь карту процедурно, то и навигационные точки расставить сможешь процедурно. При этом твои навигационные точки могут быть даже лучше того, что может предложить навмеш, т.к. никто не знает твою задумку в плане движения по карте лучше тебя.
Касательно паркура, рекомендую начать с игрового персонажа, который полностью подчиняется всем действиям игрока напрямую - управление на WASD как в шутерах. Научи этого персонажа карабкаться по стенам или выступам, перепрыгивать препятствия, делать трюки в воздухе и прочее подобное. Это даст тебе основу для NPC, потому что мозгам NPC нужно только выбирать правильное действие в конкретной ситуации. Логика выбора действия будет зависеть от информации на карте и/или рейкастов.
При этом размещать информацию прямо на карте (типа Area3D вокруг бревна, предлагающая NPC выбрать "крутой прыжок с кувырком" вместо "прыжок") должно быть производительнее и проще в реализации, чем делать сложную систему распознавания ситуации без информации на карте (т.е. анализировать форму и размер препятствия, ощупывая его множеством рейкастов и пытаясь отличить "бревно с сучками" от "бревно без сучков", чтобы сделать выбор между "крутой прыжок с кувырком" и "прыжок"). Опять же, процедурно налепить этих специальных маркеров будет не сложнее, чем сгенерировать базовую карту - достаточно добавить новый маркер "прыгни с кувырком" в сцену "бревно" (или "бревно с сучками"), которая у тебя уже как-то размещается на твоих процедурных картах - ничего кроме этого в генерации не изменится.
Также, хотя у тебя на скриншотах только капсулы, рекомендую заранее абстрагировать физику персонажей от их графического представления. Секрет 3D персонажей в том, что они изображают графически много всего, что физически в игре просто не существует. Физически у тебя движется только капсула, возможно, намного толще и выше видимой на экране модельки персонажа. А моделька регистрирует это движение капсулы и выбирает, какую анимацию ей нужно использовать, куда ставить ноги и т.п. В том же паркуре, например, физическая капсула может просто телепортироваться сквозь стену прямо перед ней, тогда как визуальная моделька персонажа будет несколько секунд проигрывать анимацию "карабкаюсь на стенку, переваливаюсь через стенку и приземляюсь с другой стороны". Хитбоксы, кстати, вообще отдельная от физики движения тема: они должны точно повторять форму и движение визуальной модели, но ни с чем не должны физически взаимодействовать - только регистрировать столкновение с другими хитбоксами.
Всё это сложно уложить в голове, т.к. в популярных играх мы обычно не видим никаких коллизий, и мозг воспринимает визуальную модельку на экране как первичное тело персонажа, тогда как в реальности она вторична и не соответствует реальной игровой физике. По этой же причине, работая с жёлтыми капсулами на твоих скриншотах, ты можешь испытывать ощущение "как-то оно неправильно двигается", хотя всё нормально. Вообще, игры строятся из иллюзий и обмана восприятия игрока, там редко бывают "честные симуляции".
Что мы имеем в итоге:
1. Поиск пути выбирает грубый, но проходимый набор точек маршрута из А в Б.
2. Физическая капсула движется по точкам, проскальзывая мелкие препятствия.
3. Визуальная моделька следует вслед за капсулой, правильно ставя ноги и т.д.
4. Карта сообщает персонажу, какие трюки можно использовать прямо сейчас.
5. Визуальная моделька проигрывает анимации трюков по запросу персонажа.
Если хочешь совсем без меток-триггеров, размещённых на карте, то придётся отказаться и от поиска пути в обычном для игр понимании. Технически ты можешь обвесить своего персонажа большим массивом рейкастов и отправлять данные с этого массива в нейросеть, которую можно тренировать обучением с подкреплением - то есть, если твой персонаж смог продвинуться чуть дальше по карте, нейросеть будет получать "награду" (плюс к значениям весов соединений между нейронами), а если персонаж не продвигается или отступает, нейросеть получает "наказание" (минус к весам). Также потребуется иногда принуждать нейронку выбирать необычные действия, иначе она застрянет на локальном оптимуме. Если массив рейкастов даёт достаточно информации для решения, достаточно крупная нейросеть рано или поздно научится проходить карты произвольной формы наиболее эффективным способом. Но помимо рейкастов (т.е. расстояния до препятствия) может потребоваться отправлять информацию о материалах, например, если у тебя движение через высокую траву медленнее движения по тропинке, или если на карте есть какие-то смертельные ловушки и т.п. При этом нужно понимать, что нейронка будет тренироваться очень долго и первое время будет ужасно тупой, а заранее определить наверняка, обучится она чему-то или нет, в общем случае невозможно.
Собственно, навмеши - это и есть "метки-триггеры", только в обобщённом смысле и для прямолинейного движения по относительно плоским поверхностям, которые можно разделить на полигоны. AStar - для движения по точкам в произвольном пространстве, хоть в четырёхмерном, но метки откуда-то должны изначально взяться. Нейросеть с рейкастами может ориентироваться в любом пространстве совсем без меток, но ей для этого потребуется долго обучаться на примерах правильного и неправильного движения.
Конечно же, ты можешь обвесить своих персонажей портянкой if elif elif elif else, но это будет сложно.
Как понимаешь, ждать чуда от новых версий движка в плане навигации персонажей бесполезно.
>>38992
Полистал. Людей, которые организовывали индексы, надо под лоботомию пустить, чтобы они ничего никогда больше не пытались организовывать. Ебаная каша.
>Открываешь https://tvtropes.org/ и собираешь в свою игру всё интересное.
Полистал. Людей, которые организовывали индексы, надо под лоботомию пустить, чтобы они ничего никогда больше не пытались организовывать. Ебаная каша.
анон. нормально ли делать такую архитектуру проекта? в сцене лишь один скрипт, поэтому я решил что сделать папку со сценами и скриптами и раздельно добавить - добро. мнение?
>>39090
Главное, чтобы тебе было удобно и ты довёл проект до релиза. Всё остальное - хуита.
> мнение?
Главное, чтобы тебе было удобно и ты довёл проект до релиза. Всё остальное - хуита.
>>39090
Тоже так делаю. Строго и удобно. В прошлых проектах хранил скрипты рядом со сценами - был вайб каши.
Тоже так делаю. Строго и удобно. В прошлых проектах хранил скрипты рядом со сценами - был вайб каши.
74 Кб, 1385x1067>>39090
Лично у меня архитектура такова, что каждый объект лежит в своей папочке с именем объекта, внутри все необходимые файлы: сцены, скрипты, звуки, модели/текстуры, однако имеется папочка shared в которой сложены общие ресурсы, которые юзаются разными обьектами, например в shared\scripts лежат общие скрипты
Лично у меня архитектура такова, что каждый объект лежит в своей папочке с именем объекта, внутри все необходимые файлы: сцены, скрипты, звуки, модели/текстуры, однако имеется папочка shared в которой сложены общие ресурсы, которые юзаются разными обьектами, например в shared\scripts лежат общие скрипты
Проблема такая: не отображается массив строк на сцене. Должно работать как в визуальных новеллах: клик по области приводит к изменению строки. У меня это реализовано следующим образом (см. скриншоты). Вопрос: что не так?
>>39105
Для начала вставь print([lineIndex, currentLinesArray]) на 34 строке, чтобы знать что оно срабатывает вообще
Для начала вставь print([lineIndex, currentLinesArray]) на 34 строке, чтобы знать что оно срабатывает вообще
>>39178
Давайте не будем вскрывать эту тему, это не для пытливых, стоп не архивы. Всё, проехали.
Подсказка есть в шапке ньюфаготреда. Однажды это может спасти вашу жисть.
Давайте не будем вскрывать эту тему, это не для пытливых, стоп не архивы. Всё, проехали.
Подсказка есть в шапке ньюфаготреда. Однажды это может спасти вашу жисть.
>>39179
Хочешь сказать тут мочератор живой завелся? Фантастика.
Ну ладно. Пойду дальше делать свою игру на годоте.
Хочешь сказать тут мочератор живой завелся? Фантастика.
Ну ладно. Пойду дальше делать свою игру на годоте.
>>39179
А если полистать тред, то видно что может и испортить - половина ответов ссылается вникуда.
А если полистать тред, то видно что может и испортить - половина ответов ссылается вникуда.
5 Кб, 328x104>>39090 >>39100 >>39102
Если у вас во всём проекте меньше десятка сцен и меньше десятка скриптов, тогда вообще без разницы где их складывать, хоть сваливайте всё в корень res://, не создавая никаких папок. Вот попробуете сделать что-то сложнее однокнопочного кликера, тогда быстро сами придёте к удобному расположению файлов. Перемещать файлы и папки в Godot не так страшно, как об этом некоторые хейтеры пишут. Даже если что-то сломается, файлы легко починить... Но для этого следует использовать форматы .tscn/.tres (открываются как текстовые файлы в любом "Блокноте"). В экспортированном проекте всё будет в бинарных .scn/.res независимо от исходных файлов.
>>39105
Во-первых, проверь, что у тебя подключён сигнал к обработчику "_on_input_event". В отличие от обработчиков типа "_ready", "_process", "_input" и некоторых других, данный обработчик нужно подключать явным образом - через визуальный редактор на вкладке сигналов или через Signal.connect() в коде. При подключении через визуальный редактор должна появиться зелёная иконка рядом с номером строки, обозначающая подключённый обработчик сигнала. Но в некоторых ситуациях это подключение через редактор ломается, например, если ты что-то переименовал и ссылка внутри сцены стала неправильной. Проще всего отключить сигнал и заново подключить, чем разбираться.
Во-вторых, проверь в настройках проекта эмуляцию тачскрина мышью. Если не ошибаюсь, по умолчанию включена эмуляция мыши через тачскрин (чтобы GUI работал на мобилках так же, как на ПК), но не наоборот. Без эмуляции тачскрина на ПК события тачскрина не срабатывают. Если тебе не нужен мультитач (одновременная регистрация сразу нескольких пальцев на экране), то имеет смысл вообще не трогать события тачскрина и работать только с событиями мыши (которая эмулируется на мобилках).
Также рекомендую следовать стайлгайду:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html#naming-conventions
Имена файлов, переменных и методов пишутся в snake_case. Это никак не влияет на работоспособность и производительность кода, но читать такие названия удобнее, потому что они соответствуют API Godot и множеству доступных онлайн проектов - мозгу не приходится лишний раз переключаться между разными стилями. Я понимаю, что ты, видимо, перешёл с другого языка, на котором используется camelCase для переменных и PascalCase для файлов, но имеет смысл соблюдать рекомендации языка, на котором пишешь код.
Если у вас во всём проекте меньше десятка сцен и меньше десятка скриптов, тогда вообще без разницы где их складывать, хоть сваливайте всё в корень res://, не создавая никаких папок. Вот попробуете сделать что-то сложнее однокнопочного кликера, тогда быстро сами придёте к удобному расположению файлов. Перемещать файлы и папки в Godot не так страшно, как об этом некоторые хейтеры пишут. Даже если что-то сломается, файлы легко починить... Но для этого следует использовать форматы .tscn/.tres (открываются как текстовые файлы в любом "Блокноте"). В экспортированном проекте всё будет в бинарных .scn/.res независимо от исходных файлов.
>>39105
Во-первых, проверь, что у тебя подключён сигнал к обработчику "_on_input_event". В отличие от обработчиков типа "_ready", "_process", "_input" и некоторых других, данный обработчик нужно подключать явным образом - через визуальный редактор на вкладке сигналов или через Signal.connect() в коде. При подключении через визуальный редактор должна появиться зелёная иконка рядом с номером строки, обозначающая подключённый обработчик сигнала. Но в некоторых ситуациях это подключение через редактор ломается, например, если ты что-то переименовал и ссылка внутри сцены стала неправильной. Проще всего отключить сигнал и заново подключить, чем разбираться.
Во-вторых, проверь в настройках проекта эмуляцию тачскрина мышью. Если не ошибаюсь, по умолчанию включена эмуляция мыши через тачскрин (чтобы GUI работал на мобилках так же, как на ПК), но не наоборот. Без эмуляции тачскрина на ПК события тачскрина не срабатывают. Если тебе не нужен мультитач (одновременная регистрация сразу нескольких пальцев на экране), то имеет смысл вообще не трогать события тачскрина и работать только с событиями мыши (которая эмулируется на мобилках).
Также рекомендую следовать стайлгайду:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html#naming-conventions
Имена файлов, переменных и методов пишутся в snake_case. Это никак не влияет на работоспособность и производительность кода, но читать такие названия удобнее, потому что они соответствуют API Godot и множеству доступных онлайн проектов - мозгу не приходится лишний раз переключаться между разными стилями. Я понимаю, что ты, видимо, перешёл с другого языка, на котором используется camelCase для переменных и PascalCase для файлов, но имеет смысл соблюдать рекомендации языка, на котором пишешь код.
5 Кб, 328x104>>39090 >>39100 >>39102
Если у вас во всём проекте меньше десятка сцен и меньше десятка скриптов, тогда вообще без разницы где их складывать, хоть сваливайте всё в корень res://, не создавая никаких папок. Вот попробуете сделать что-то сложнее однокнопочного кликера, тогда быстро сами придёте к удобному расположению файлов. Перемещать файлы и папки в Godot не так страшно, как об этом некоторые хейтеры пишут. Даже если что-то сломается, файлы легко починить... Но для этого следует использовать форматы .tscn/.tres (открываются как текстовые файлы в любом "Блокноте"). В экспортированном проекте всё будет в бинарных .scn/.res независимо от исходных файлов.
>>39105
Во-первых, проверь, что у тебя подключён сигнал к обработчику "_on_input_event". В отличие от обработчиков типа "_ready", "_process", "_input" и некоторых других, данный обработчик нужно подключать явным образом - через визуальный редактор на вкладке сигналов или через Signal.connect() в коде. При подключении через визуальный редактор должна появиться зелёная иконка рядом с номером строки, обозначающая подключённый обработчик сигнала. Но в некоторых ситуациях это подключение через редактор ломается, например, если ты что-то переименовал и ссылка внутри сцены стала неправильной. Проще всего отключить сигнал и заново подключить, чем разбираться.
Во-вторых, проверь в настройках проекта эмуляцию тачскрина мышью. Если не ошибаюсь, по умолчанию включена эмуляция мыши через тачскрин (чтобы GUI работал на мобилках так же, как на ПК), но не наоборот. Без эмуляции тачскрина на ПК события тачскрина не срабатывают. Если тебе не нужен мультитач (одновременная регистрация сразу нескольких пальцев на экране), то имеет смысл вообще не трогать события тачскрина и работать только с событиями мыши (которая эмулируется на мобилках).
Также рекомендую следовать стайлгайду:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html#naming-conventions
Имена файлов, переменных и методов пишутся в snake_case. Это никак не влияет на работоспособность и производительность кода, но читать такие названия удобнее, потому что они соответствуют API Godot и множеству доступных онлайн проектов - мозгу не приходится лишний раз переключаться между разными стилями. Я понимаю, что ты, видимо, перешёл с другого языка, на котором используется camelCase для переменных и PascalCase для файлов, но имеет смысл соблюдать рекомендации языка, на котором пишешь код.
Если у вас во всём проекте меньше десятка сцен и меньше десятка скриптов, тогда вообще без разницы где их складывать, хоть сваливайте всё в корень res://, не создавая никаких папок. Вот попробуете сделать что-то сложнее однокнопочного кликера, тогда быстро сами придёте к удобному расположению файлов. Перемещать файлы и папки в Godot не так страшно, как об этом некоторые хейтеры пишут. Даже если что-то сломается, файлы легко починить... Но для этого следует использовать форматы .tscn/.tres (открываются как текстовые файлы в любом "Блокноте"). В экспортированном проекте всё будет в бинарных .scn/.res независимо от исходных файлов.
>>39105
Во-первых, проверь, что у тебя подключён сигнал к обработчику "_on_input_event". В отличие от обработчиков типа "_ready", "_process", "_input" и некоторых других, данный обработчик нужно подключать явным образом - через визуальный редактор на вкладке сигналов или через Signal.connect() в коде. При подключении через визуальный редактор должна появиться зелёная иконка рядом с номером строки, обозначающая подключённый обработчик сигнала. Но в некоторых ситуациях это подключение через редактор ломается, например, если ты что-то переименовал и ссылка внутри сцены стала неправильной. Проще всего отключить сигнал и заново подключить, чем разбираться.
Во-вторых, проверь в настройках проекта эмуляцию тачскрина мышью. Если не ошибаюсь, по умолчанию включена эмуляция мыши через тачскрин (чтобы GUI работал на мобилках так же, как на ПК), но не наоборот. Без эмуляции тачскрина на ПК события тачскрина не срабатывают. Если тебе не нужен мультитач (одновременная регистрация сразу нескольких пальцев на экране), то имеет смысл вообще не трогать события тачскрина и работать только с событиями мыши (которая эмулируется на мобилках).
Также рекомендую следовать стайлгайду:
https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_styleguide.html#naming-conventions
Имена файлов, переменных и методов пишутся в snake_case. Это никак не влияет на работоспособность и производительность кода, но читать такие названия удобнее, потому что они соответствуют API Godot и множеству доступных онлайн проектов - мозгу не приходится лишний раз переключаться между разными стилями. Я понимаю, что ты, видимо, перешёл с другого языка, на котором используется camelCase для переменных и PascalCase для файлов, но имеет смысл соблюдать рекомендации языка, на котором пишешь код.
>>39090
Мне было бы не удобно как у тебя.
У меня похоже на >>39104, но только у меня разграничение между ресурсами и ассетами. Условно ресурсы - это что в годоте редачится, а ассеты - это звуки, картинки, модели и тд.
типа resources/controllers/player.tscn
resources/controllers/player.gd
src/models/player/player.glb
src/sounds/sfx/player/yawn.ogg
У меня в основном объекты пустые и я гружу в них ресы через иниты/криэйты. И таклц подход работает классно и быстро. Но в целом соглашусь - ебаш как удобно
Мне было бы не удобно как у тебя.
У меня похоже на >>39104, но только у меня разграничение между ресурсами и ассетами. Условно ресурсы - это что в годоте редачится, а ассеты - это звуки, картинки, модели и тд.
типа resources/controllers/player.tscn
resources/controllers/player.gd
src/models/player/player.glb
src/sounds/sfx/player/yawn.ogg
У меня в основном объекты пустые и я гружу в них ресы через иниты/криэйты. И таклц подход работает классно и быстро. Но в целом соглашусь - ебаш как удобно
>>39090
Я пытался разделять скрипты со сценами, но понял что это просто дополнительный головняк ради визуального перфекционизма. В итоге меньше движений совершается если иметь одно общее дерево, чем два повторяющихся. А так делай как тебе нравится, без команды похуй абсолютно.
Я пытался разделять скрипты со сценами, но понял что это просто дополнительный головняк ради визуального перфекционизма. В итоге меньше движений совершается если иметь одно общее дерево, чем два повторяющихся. А так делай как тебе нравится, без команды похуй абсолютно.
780 Кб, mp4,1280x720, 0:15
>>38995
Игру я, конечно, делать не буду...
Игру я, конечно, делать не буду...
>>39362
Пили на отечественном движке, НУЕ или както так. Алсо, итч тоже не пашет без впн и уже очень давно. Врядли это таргетно, под раздачу щас все подряд улетает, вот только вчера у меня твич не работал вообще, а сегодня уже норм.
Пили на отечественном движке, НУЕ или както так. Алсо, итч тоже не пашет без впн и уже очень давно. Врядли это таргетно, под раздачу щас все подряд улетает, вот только вчера у меня твич не работал вообще, а сегодня уже норм.
>>39362
У меня давно так. И документация и сайт.
Итч тоже, как у анона выше, но частично - сайт грузится, а его картинки нет, поэтому тоже хожу на него через впн.
У меня давно так. И документация и сайт.
Итч тоже, как у анона выше, но частично - сайт грузится, а его картинки нет, поэтому тоже хожу на него через впн.
>>39363
Либо проблема у твоего провайдера, либо сбрось DNS кэш на роутере. Итч пару месяцев назад испытывал проблемы со своим хостером (их забанило автоматом из-за слоупоков в техподдержке и автоматического DMCA-бота копирайт троллей), переехал к другому хостеру и поменял IP адрес. Некоторые роутеры могут хранить DNS записи очень долго.
>>39362
Это бывает, когда у твоего провайдера проблемы с доступом к сервисам Cloudflare. Сайт https://godotengine.org/ находится в облаке/сети Cloudflare (можешь сам проверить whois). Когда РКН в мае пытался заблокировать всю сеть Cloudflare разом, у нас бОльшая часть рунета рухнула (домены типа .ru/.su/.рф) и бОльшая часть всего остального интернета, потому что Cloudflare практически монополист. РКН сказал что-то вроде "пользуйтесь локальными сервисами", но у нас нет локальной альтернативы Cloudflare. Поэтому эти блокировки уже давно откатили и доступ к Cloudflare восстановился. Но у разных провайдеров по-разному. В какой-нибудь деревне могут месяцами настройки не обновлять на сетевом оборудовании, наверное...
>итч тоже не пашет без впн и уже очень давно
Либо проблема у твоего провайдера, либо сбрось DNS кэш на роутере. Итч пару месяцев назад испытывал проблемы со своим хостером (их забанило автоматом из-за слоупоков в техподдержке и автоматического DMCA-бота копирайт троллей), переехал к другому хостеру и поменял IP адрес. Некоторые роутеры могут хранить DNS записи очень долго.
>>39362
>сайт годо только с VPN открывается
Это бывает, когда у твоего провайдера проблемы с доступом к сервисам Cloudflare. Сайт https://godotengine.org/ находится в облаке/сети Cloudflare (можешь сам проверить whois). Когда РКН в мае пытался заблокировать всю сеть Cloudflare разом, у нас бОльшая часть рунета рухнула (домены типа .ru/.su/.рф) и бОльшая часть всего остального интернета, потому что Cloudflare практически монополист. РКН сказал что-то вроде "пользуйтесь локальными сервисами", но у нас нет локальной альтернативы Cloudflare. Поэтому эти блокировки уже давно откатили и доступ к Cloudflare восстановился. Но у разных провайдеров по-разному. В какой-нибудь деревне могут месяцами настройки не обновлять на сетевом оборудовании, наверное...
>>38944
Туториалы это самая сложная часть игры. Игрок тупой и не хочет читать, но думает что он самый умный, а потом бежит плакаться в комменты, что игра говно. Лично на стриме по своей игре видел, как стример тупил над механикой, потому что скипнул туториал он ж самый умный про-геймер и ему почти все поддакивали.
Туториалы это самая сложная часть игры. Игрок тупой и не хочет читать, но думает что он самый умный, а потом бежит плакаться в комменты, что игра говно. Лично на стриме по своей игре видел, как стример тупил над механикой, потому что скипнул туториал он ж самый умный про-геймер и ему почти все поддакивали.
>>39389
Ну так это не говорит о том, что сложно сделать туториал. В крайнем случае о том, что сложно найти игрока, который станет его проходить.
Или сложно придумать обучающий уровень, который попросту нельзя скипнуть? Ну хз.
>скипнул туториал
Ну так это не говорит о том, что сложно сделать туториал. В крайнем случае о том, что сложно найти игрока, который станет его проходить.
Или сложно придумать обучающий уровень, который попросту нельзя скипнуть? Ну хз.
>>39423
Сложно научить игрока играть в игру средствами самой игры.
>>39389
Может, стоило представлять механику в более интуитивно понятном виде? Лучший туториал - это отсутствие туториала. Старые ОС и программы имели GUI, очень сильно похожий на реальные и распространённые в реальной жизни вещи, наиболее яркий пример - иконки на кнопках часто изображают реальный объект с похожей функцией. Сама по себе GUI кнопка - это сознательная имитация реальных выпуклых кнопок на реальных приборах, потому что простой прямоугольник не всегда понимается как то, на что можно/нужно кликнуть мышкой. Т.е. GUI специально проектировали так, чтобы даже домохозяйка могла разобраться в компьютере, если она уже обучена взаимодействовать с дисковым телефоном, граммофоном, магнитофоном и т.д. Сейчас от этой концепции отошли в сторону упрощения, потому что выросло несколько поколений, с детства взаимодействующих с компьютерами - им теперь наоборот, реальные вещи нужно объяснять компьютерными терминами...
Поэтому если возможно, делай все механики интуитивно понятными, как в реальности. Если невозможно - тогда делай туториал непропускаемым: чтобы не было кнопки "пропустить" и игрок был обязан совершить необходимое по механике действие своими руками. А если требуется что-то объяснить прямым текстом, то прячь кнопку "ок" под скроллом и блокируй на несколько секунд после появления окна. Конечно, так туториал станет неприятнее для игрока, который всё с первого взгляда всё понял, но что поделать? Ты уже проиграл эту борьбу, если не смог сделать механику достаточно интуитивной для широкой аудитории и прибег к туториалу. Остаётся только принуждать игрока разбираться с этой твоей механикой через силу.
Сложно научить игрока играть в игру средствами самой игры.
>>39389
>тупил над механикой, потому что скипнул туториал
Может, стоило представлять механику в более интуитивно понятном виде? Лучший туториал - это отсутствие туториала. Старые ОС и программы имели GUI, очень сильно похожий на реальные и распространённые в реальной жизни вещи, наиболее яркий пример - иконки на кнопках часто изображают реальный объект с похожей функцией. Сама по себе GUI кнопка - это сознательная имитация реальных выпуклых кнопок на реальных приборах, потому что простой прямоугольник не всегда понимается как то, на что можно/нужно кликнуть мышкой. Т.е. GUI специально проектировали так, чтобы даже домохозяйка могла разобраться в компьютере, если она уже обучена взаимодействовать с дисковым телефоном, граммофоном, магнитофоном и т.д. Сейчас от этой концепции отошли в сторону упрощения, потому что выросло несколько поколений, с детства взаимодействующих с компьютерами - им теперь наоборот, реальные вещи нужно объяснять компьютерными терминами...
Поэтому если возможно, делай все механики интуитивно понятными, как в реальности. Если невозможно - тогда делай туториал непропускаемым: чтобы не было кнопки "пропустить" и игрок был обязан совершить необходимое по механике действие своими руками. А если требуется что-то объяснить прямым текстом, то прячь кнопку "ок" под скроллом и блокируй на несколько секунд после появления окна. Конечно, так туториал станет неприятнее для игрока, который всё с первого взгляда всё понял, но что поделать? Ты уже проиграл эту борьбу, если не смог сделать механику достаточно интуитивной для широкой аудитории и прибег к туториалу. Остаётся только принуждать игрока разбираться с этой твоей механикой через силу.
>>39389
Я бы тоже скипнул, если он меня инфодампит. Лучшие игры либо не имеют туториала вообще, либо он встроен в игру незаметным образом. Вспомни Портал. Обучение там было, но ты не мог его скипнуть и оно ощущалось как игра, а не как учебник который надо выучить чтобы просто посмотреть что за хуйню я скачал - такое делать просто влом. У меня таких игр еще десятка два скачанных лежит, и в итоге я поиграю в ту, которая дает мне поиграть.
Я бы тоже скипнул, если он меня инфодампит. Лучшие игры либо не имеют туториала вообще, либо он встроен в игру незаметным образом. Вспомни Портал. Обучение там было, но ты не мог его скипнуть и оно ощущалось как игра, а не как учебник который надо выучить чтобы просто посмотреть что за хуйню я скачал - такое делать просто влом. У меня таких игр еще десятка два скачанных лежит, и в итоге я поиграю в ту, которая дает мне поиграть.
>>39277
О каком сигнале идет речь? До этого изучал C, и для меня все эти высокоуровневые абстракции - густой и темный лес. Я понимаю, что имеется ввиду вкладка Node и соответствующие пункты, но что именно мне там нужно?
Поставил галочку. Никакой реакции как и прежде. Прописал строку для отладки, как посоветовал >>39141-анон, в консоли пустота.
>Во-первых, проверь, что у тебя подключён сигнал к обработчику "_on_input_event"
О каком сигнале идет речь? До этого изучал C, и для меня все эти высокоуровневые абстракции - густой и темный лес. Я понимаю, что имеется ввиду вкладка Node и соответствующие пункты, но что именно мне там нужно?
>Во-вторых, проверь в настройках проекта эмуляцию тачскрина мышью
Поставил галочку. Никакой реакции как и прежде. Прописал строку для отладки, как посоветовал >>39141-анон, в консоли пустота.
46 Кб, 575x455И есть еще одна проблема. Дальше второй сцены (первая, соответственно - главное меню) перемещение не происходит. Код для кнопки перемещения представлен на скриншоте. sceneIndex просто перестает расти.
>>39485
После смены сцены этот скрипт обнуляется и sceneIndex снова становится = 0, нужно или в глобальном скрипте хранить или в сцене завести какой нибудь currentSceneIndex
После смены сцены этот скрипт обнуляется и sceneIndex снова становится = 0, нужно или в глобальном скрипте хранить или в сцене завести какой нибудь currentSceneIndex
>>39479
Выбери элемент, клик по которому нужен, допустим это Label
Во вкладке Node-Signals дважды щёлкни по gui_input(...)
В открывшимся окне укажи ноду со скриптом, допустим это опять Label
в скрипте Label появится функция-пустышка, увидишь и у неё будет иконка, вот там должен будет быть код функции _on_input_event
>О каком сигнале идет речь? До этого изучал C, и для меня все эти высокоуровневые абстракции - густой и темный лес. Я понимаю, что имеется ввиду вкладка Node и соответствующие пункты, но что именно мне там нужно?
Выбери элемент, клик по которому нужен, допустим это Label
Во вкладке Node-Signals дважды щёлкни по gui_input(...)
В открывшимся окне укажи ноду со скриптом, допустим это опять Label
в скрипте Label появится функция-пустышка, увидишь и у неё будет иконка, вот там должен будет быть код функции _on_input_event
>>39485
А что если тебе по другому пути пойти? Если предполагается, что все сцены проходятся по порядку, то не надо хранить все сцены в одном списке. Пусть у тебя будет кнопка, которая у себя в скрипте хранит экспортную переменную для сцены:
@export var next_scene: PackedScene
И ты её для каждой такой кнопки сможешь задавать индивидуально. И да, это пакованная сцена, а не путь, что разом решает кучу проблем с путями.
Далее, при нажатии тебе не надо никаких счётчиков и инкрементов. Если сцена есть - то переключаем её.
Круто, удобно, с инспектором совместимо.
А что если тебе по другому пути пойти? Если предполагается, что все сцены проходятся по порядку, то не надо хранить все сцены в одном списке. Пусть у тебя будет кнопка, которая у себя в скрипте хранит экспортную переменную для сцены:
@export var next_scene: PackedScene
И ты её для каждой такой кнопки сможешь задавать индивидуально. И да, это пакованная сцена, а не путь, что разом решает кучу проблем с путями.
Далее, при нажатии тебе не надо никаких счётчиков и инкрементов. Если сцена есть - то переключаем её.
> if next_scene: get_tree().change_scene_to_packed(next_scene)
Круто, удобно, с инспектором совместимо.
>>39479
Ивенты. Впервые ивенты переименовали в сигналы линуксоиды ГТК, шоб не как у виндузятников (например https://zetcode.com/gui/gtk2/gtkevents/ ).
> О каком сигнале идет речь? До этого изучал C
Ивенты. Впервые ивенты переименовали в сигналы линуксоиды ГТК, шоб не как у виндузятников (например https://zetcode.com/gui/gtk2/gtkevents/ ).
562 Кб, 2048x2048>>39701
Не путай его дальше.
Эвенты и сигналы это разные сущности. Эвент - предопределён и заложен в объект/систему, сигнал - может быть чем угодно(даже эвентом или двумя) , в Qt есть и эвенты и сигналы например.
В годо назвали как смогли.
Не путай его дальше.
Эвенты и сигналы это разные сущности. Эвент - предопределён и заложен в объект/систему, сигнал - может быть чем угодно(даже эвентом или двумя) , в Qt есть и эвенты и сигналы например.
В годо назвали как смогли.
>>39722
Ну куда мне до него? Он же СИ изучал. Это я первее запутаюсь, дельфист простой.
> Не путай его дальше.
Ну куда мне до него? Он же СИ изучал. Это я первее запутаюсь, дельфист простой.
>>39722
Наблюдатель, EventBus, все до чего дотянется по теме и пусть дальше сам решает, как это называть.
Его демку неплохо оценили на стримах кста.
>Не путай его дальше.
Наблюдатель, EventBus, все до чего дотянется по теме и пусть дальше сам решает, как это называть.
Его демку неплохо оценили на стримах кста.
943 Кб, 1586x753>>39499
Не работает. Структура сцены такая (как всегда, знаете где смотреть). В чем же я не прав...
>>39684
Как это работает? Я не понимаю, я пропишу эту строчку и типа все само заработает? А почему? Вот хреново же работать на неизвестном наборе инструментов, не имея времени разбираться в нем. Но это выбрала команда.
Не работает. Структура сцены такая (как всегда, знаете где смотреть). В чем же я не прав...
>>39684
>@export var next_scene: PackedScene
>И ты её для каждой такой кнопки сможешь задавать индивидуально. И да, это пакованная сцена, а не путь, что разом решает кучу проблем с путями.
Как это работает? Я не понимаю, я пропишу эту строчку и типа все само заработает? А почему? Вот хреново же работать на неизвестном наборе инструментов, не имея времени разбираться в нем. Но это выбрала команда.
>>39738
Смотри, как только ты пропишешь в скрипте @export эта переменная появится в инспекторе обьектов при клике на ноду со скриптом, то есть в твоём случае на кнопке. То есть, иначе говоря, мы таким образом выносим настройки в редактор, экспортируем их.
Далее твои действия: добавить кнопку-переходилку, указать в инспекторе сцену, куда переходить, и всё. В игре эта кнопка при нажатии игроком переключит сцену на указанную у неё в настройках.
> Как это работает? Я не понимаю
Смотри, как только ты пропишешь в скрипте @export эта переменная появится в инспекторе обьектов при клике на ноду со скриптом, то есть в твоём случае на кнопке. То есть, иначе говоря, мы таким образом выносим настройки в редактор, экспортируем их.
Далее твои действия: добавить кнопку-переходилку, указать в инспекторе сцену, куда переходить, и всё. В игре эта кнопка при нажатии игроком переключит сцену на указанную у неё в настройках.
>>39479
Если хочешь глубже разобраться в этих концепциях, то это где-то тут:
http://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
http://ru.wikipedia.org/wiki/Callback_(программирование)
http://ru.wikipedia.org/wiki/Наблюдатель_(шаблон_проектирования)
Но в контексте Godot будет достаточно прочитать это:
http://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
http://docs.godotengine.org/en/stable/classes/class_signal.html
>>39485
Метод "change_scene_to..." ЗАМЕНЯЕТ всё, что у тебя в дереве (кроме autoload).
Рекомендую вместо этого метода распоряжаться всем самостоятельно, пикрил.
Autoload'ы не рекомендую, они глубоко в настройках + это глобальная лапша.
Официальная документация на эту тему:
https://docs.godotengine.org/en/stable/tutorials/scripting/change_scenes_manually.html
Также разберись с тем, как вообще работает дерево сцен, ноды и сцены:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_tree.html
https://docs.godotengine.org/en/stable/tutorials/scripting/nodes_and_scene_instances.html
А вообще, лучше читать всё по порядку в официальной документации.
>>39738
Ты же знаешь, что многие настройки скрыты из GUI, но имеются внутри .tscn?
Лол. Так ты далеко не уедешь. Лучше выдели пару часов вечером и разберись.
>>39754
Он буквально нулевой новичок и тычется в GUI редактора, не читая документацию...
>для меня все эти высокоуровневые абстракции - густой и темный лес
Если хочешь глубже разобраться в этих концепциях, то это где-то тут:
http://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
http://ru.wikipedia.org/wiki/Callback_(программирование)
http://ru.wikipedia.org/wiki/Наблюдатель_(шаблон_проектирования)
Но в контексте Godot будет достаточно прочитать это:
http://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
http://docs.godotengine.org/en/stable/classes/class_signal.html
>>39485
>Дальше второй сцены перемещение не происходит.
Метод "change_scene_to..." ЗАМЕНЯЕТ всё, что у тебя в дереве (кроме autoload).
Рекомендую вместо этого метода распоряжаться всем самостоятельно, пикрил.
Autoload'ы не рекомендую, они глубоко в настройках + это глобальная лапша.
Официальная документация на эту тему:
https://docs.godotengine.org/en/stable/tutorials/scripting/change_scenes_manually.html
Также разберись с тем, как вообще работает дерево сцен, ноды и сцены:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_tree.html
https://docs.godotengine.org/en/stable/tutorials/scripting/nodes_and_scene_instances.html
А вообще, лучше читать всё по порядку в официальной документации.
>>39738
>Структура сцены такая
Ты же знаешь, что многие настройки скрыты из GUI, но имеются внутри .tscn?
>работать на неизвестном наборе инструментов, не имея времени разбираться
Лол. Так ты далеко не уедешь. Лучше выдели пару часов вечером и разберись.
>>39754
Он буквально нулевой новичок и тычется в GUI редактора, не читая документацию...
>>39479
Если хочешь глубже разобраться в этих концепциях, то это где-то тут:
http://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
http://ru.wikipedia.org/wiki/Callback_(программирование)
http://ru.wikipedia.org/wiki/Наблюдатель_(шаблон_проектирования)
Но в контексте Godot будет достаточно прочитать это:
http://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
http://docs.godotengine.org/en/stable/classes/class_signal.html
>>39485
Метод "change_scene_to..." ЗАМЕНЯЕТ всё, что у тебя в дереве (кроме autoload).
Рекомендую вместо этого метода распоряжаться всем самостоятельно, пикрил.
Autoload'ы не рекомендую, они глубоко в настройках + это глобальная лапша.
Официальная документация на эту тему:
https://docs.godotengine.org/en/stable/tutorials/scripting/change_scenes_manually.html
Также разберись с тем, как вообще работает дерево сцен, ноды и сцены:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_tree.html
https://docs.godotengine.org/en/stable/tutorials/scripting/nodes_and_scene_instances.html
А вообще, лучше читать всё по порядку в официальной документации.
>>39738
Ты же знаешь, что многие настройки скрыты из GUI, но имеются внутри .tscn?
Лол. Так ты далеко не уедешь. Лучше выдели пару часов вечером и разберись.
>>39754
Он буквально нулевой новичок и тычется в GUI редактора, не читая документацию...
>для меня все эти высокоуровневые абстракции - густой и темный лес
Если хочешь глубже разобраться в этих концепциях, то это где-то тут:
http://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование
http://ru.wikipedia.org/wiki/Callback_(программирование)
http://ru.wikipedia.org/wiki/Наблюдатель_(шаблон_проектирования)
Но в контексте Godot будет достаточно прочитать это:
http://docs.godotengine.org/en/stable/getting_started/step_by_step/signals.html
http://docs.godotengine.org/en/stable/classes/class_signal.html
>>39485
>Дальше второй сцены перемещение не происходит.
Метод "change_scene_to..." ЗАМЕНЯЕТ всё, что у тебя в дереве (кроме autoload).
Рекомендую вместо этого метода распоряжаться всем самостоятельно, пикрил.
Autoload'ы не рекомендую, они глубоко в настройках + это глобальная лапша.
Официальная документация на эту тему:
https://docs.godotengine.org/en/stable/tutorials/scripting/change_scenes_manually.html
Также разберись с тем, как вообще работает дерево сцен, ноды и сцены:
https://docs.godotengine.org/en/stable/tutorials/scripting/scene_tree.html
https://docs.godotengine.org/en/stable/tutorials/scripting/nodes_and_scene_instances.html
А вообще, лучше читать всё по порядку в официальной документации.
>>39738
>Структура сцены такая
Ты же знаешь, что многие настройки скрыты из GUI, но имеются внутри .tscn?
>работать на неизвестном наборе инструментов, не имея времени разбираться
Лол. Так ты далеко не уедешь. Лучше выдели пару часов вечером и разберись.
>>39754
Он буквально нулевой новичок и тычется в GUI редактора, не читая документацию...
407 Кб, 498x278>>39758 >>39754
Небольшое замечание про "@export var next: PackedScene" и подобные этой конструкции.
PackedScene - потомок Resource, а любые Resource в export-полях нод загружаются с диска вместе со сценой, в которой находится эта нода. При этом сцена не может выполнить какой-либо код, пока не загрузятся с диска все ресурсы. При этом вложенные ресурсы загружают свои ресурсы и так по цепочке пока все указанные в ресурсах ресурсы не будут прочитаны с диска в память. Важно отметить, что ресурсы не могут иметь цикличных ссылок между ресурсами, то если у вас ресурс А имеет ссылку на ресурс Б, а ресурс Б имеет ссылку на ресурс А (например, две сцены, ссылающиеся друг на друга как PackedScene), то движок упадёт с ошибкой цикличной зависимости, отказавшись работать. Пока что эту проблему никак не исправили:
https://github.com/godotengine/godot-proposals/issues/7363
Но даже если все ссылки будут линейными/древовидными без циклов, нужно учитывать, сколько у вас ресурсов, сколько они весят, насколько сложно будет парсить движку (движок может несколько раз парсить один и тот же ресурс, разрешая все зависимости). По умолчанию все ресурсы грузятся в одном потоке, хотя можно использовать специальный фоновый загрузчик как, например, описано в документации:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
Но, из моего опыта, эта "фоновая" загрузка разочаровывает: у меня даже относительно простая группа сцен, вложенных в корневую сцену, вызывает ощутимые тормоза этого загрузчика, в то время как прогресс-бар отображает только "50%" (0% -> 50% -> 100%, очень информативно). Короче, загрузка длинных цепочек ресурсов может вызывать проблемы, особенно если её делать самым простым способом: если вставить ссылку в главную сцену, то окно движка будет "висеть", пока все ресурсы не загрузятся, что очень плохо с точки зрения UI/UX (пользовательского опыта).
Если загружать отдельные сцены с минимальным количеством ресурсов в них через load(), то этой проблемы нет - мы считываем только одну сцену, а не длинную цепочку из всех существующих сцен сразу. Небольшой лаг при нажатии "далее" субъективно лучше, чем ожидание нескольких минут загрузки с белым экраном и надписью "это приложение не отвечает, закрыть?" или прогресс-баром, замершем на 50% по непонятной причине. Хотя масштаб проблемы зависит от количества и размеров ресурсов в конкретной игре (на "hello world" никак не повлияет), но это всё нужно иметь в виду, особенно если планируете расширять игру в будущем дополнительным контентом.
Небольшое замечание про "@export var next: PackedScene" и подобные этой конструкции.
PackedScene - потомок Resource, а любые Resource в export-полях нод загружаются с диска вместе со сценой, в которой находится эта нода. При этом сцена не может выполнить какой-либо код, пока не загрузятся с диска все ресурсы. При этом вложенные ресурсы загружают свои ресурсы и так по цепочке пока все указанные в ресурсах ресурсы не будут прочитаны с диска в память. Важно отметить, что ресурсы не могут иметь цикличных ссылок между ресурсами, то если у вас ресурс А имеет ссылку на ресурс Б, а ресурс Б имеет ссылку на ресурс А (например, две сцены, ссылающиеся друг на друга как PackedScene), то движок упадёт с ошибкой цикличной зависимости, отказавшись работать. Пока что эту проблему никак не исправили:
https://github.com/godotengine/godot-proposals/issues/7363
Но даже если все ссылки будут линейными/древовидными без циклов, нужно учитывать, сколько у вас ресурсов, сколько они весят, насколько сложно будет парсить движку (движок может несколько раз парсить один и тот же ресурс, разрешая все зависимости). По умолчанию все ресурсы грузятся в одном потоке, хотя можно использовать специальный фоновый загрузчик как, например, описано в документации:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
Но, из моего опыта, эта "фоновая" загрузка разочаровывает: у меня даже относительно простая группа сцен, вложенных в корневую сцену, вызывает ощутимые тормоза этого загрузчика, в то время как прогресс-бар отображает только "50%" (0% -> 50% -> 100%, очень информативно). Короче, загрузка длинных цепочек ресурсов может вызывать проблемы, особенно если её делать самым простым способом: если вставить ссылку в главную сцену, то окно движка будет "висеть", пока все ресурсы не загрузятся, что очень плохо с точки зрения UI/UX (пользовательского опыта).
Если загружать отдельные сцены с минимальным количеством ресурсов в них через load(), то этой проблемы нет - мы считываем только одну сцену, а не длинную цепочку из всех существующих сцен сразу. Небольшой лаг при нажатии "далее" субъективно лучше, чем ожидание нескольких минут загрузки с белым экраном и надписью "это приложение не отвечает, закрыть?" или прогресс-баром, замершем на 50% по непонятной причине. Хотя масштаб проблемы зависит от количества и размеров ресурсов в конкретной игре (на "hello world" никак не повлияет), но это всё нужно иметь в виду, особенно если планируете расширять игру в будущем дополнительным контентом.
407 Кб, 498x278>>39758 >>39754
Небольшое замечание про "@export var next: PackedScene" и подобные этой конструкции.
PackedScene - потомок Resource, а любые Resource в export-полях нод загружаются с диска вместе со сценой, в которой находится эта нода. При этом сцена не может выполнить какой-либо код, пока не загрузятся с диска все ресурсы. При этом вложенные ресурсы загружают свои ресурсы и так по цепочке пока все указанные в ресурсах ресурсы не будут прочитаны с диска в память. Важно отметить, что ресурсы не могут иметь цикличных ссылок между ресурсами, то если у вас ресурс А имеет ссылку на ресурс Б, а ресурс Б имеет ссылку на ресурс А (например, две сцены, ссылающиеся друг на друга как PackedScene), то движок упадёт с ошибкой цикличной зависимости, отказавшись работать. Пока что эту проблему никак не исправили:
https://github.com/godotengine/godot-proposals/issues/7363
Но даже если все ссылки будут линейными/древовидными без циклов, нужно учитывать, сколько у вас ресурсов, сколько они весят, насколько сложно будет парсить движку (движок может несколько раз парсить один и тот же ресурс, разрешая все зависимости). По умолчанию все ресурсы грузятся в одном потоке, хотя можно использовать специальный фоновый загрузчик как, например, описано в документации:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
Но, из моего опыта, эта "фоновая" загрузка разочаровывает: у меня даже относительно простая группа сцен, вложенных в корневую сцену, вызывает ощутимые тормоза этого загрузчика, в то время как прогресс-бар отображает только "50%" (0% -> 50% -> 100%, очень информативно). Короче, загрузка длинных цепочек ресурсов может вызывать проблемы, особенно если её делать самым простым способом: если вставить ссылку в главную сцену, то окно движка будет "висеть", пока все ресурсы не загрузятся, что очень плохо с точки зрения UI/UX (пользовательского опыта).
Если загружать отдельные сцены с минимальным количеством ресурсов в них через load(), то этой проблемы нет - мы считываем только одну сцену, а не длинную цепочку из всех существующих сцен сразу. Небольшой лаг при нажатии "далее" субъективно лучше, чем ожидание нескольких минут загрузки с белым экраном и надписью "это приложение не отвечает, закрыть?" или прогресс-баром, замершем на 50% по непонятной причине. Хотя масштаб проблемы зависит от количества и размеров ресурсов в конкретной игре (на "hello world" никак не повлияет), но это всё нужно иметь в виду, особенно если планируете расширять игру в будущем дополнительным контентом.
Небольшое замечание про "@export var next: PackedScene" и подобные этой конструкции.
PackedScene - потомок Resource, а любые Resource в export-полях нод загружаются с диска вместе со сценой, в которой находится эта нода. При этом сцена не может выполнить какой-либо код, пока не загрузятся с диска все ресурсы. При этом вложенные ресурсы загружают свои ресурсы и так по цепочке пока все указанные в ресурсах ресурсы не будут прочитаны с диска в память. Важно отметить, что ресурсы не могут иметь цикличных ссылок между ресурсами, то если у вас ресурс А имеет ссылку на ресурс Б, а ресурс Б имеет ссылку на ресурс А (например, две сцены, ссылающиеся друг на друга как PackedScene), то движок упадёт с ошибкой цикличной зависимости, отказавшись работать. Пока что эту проблему никак не исправили:
https://github.com/godotengine/godot-proposals/issues/7363
Но даже если все ссылки будут линейными/древовидными без циклов, нужно учитывать, сколько у вас ресурсов, сколько они весят, насколько сложно будет парсить движку (движок может несколько раз парсить один и тот же ресурс, разрешая все зависимости). По умолчанию все ресурсы грузятся в одном потоке, хотя можно использовать специальный фоновый загрузчик как, например, описано в документации:
https://docs.godotengine.org/en/stable/tutorials/io/background_loading.html
Но, из моего опыта, эта "фоновая" загрузка разочаровывает: у меня даже относительно простая группа сцен, вложенных в корневую сцену, вызывает ощутимые тормоза этого загрузчика, в то время как прогресс-бар отображает только "50%" (0% -> 50% -> 100%, очень информативно). Короче, загрузка длинных цепочек ресурсов может вызывать проблемы, особенно если её делать самым простым способом: если вставить ссылку в главную сцену, то окно движка будет "висеть", пока все ресурсы не загрузятся, что очень плохо с точки зрения UI/UX (пользовательского опыта).
Если загружать отдельные сцены с минимальным количеством ресурсов в них через load(), то этой проблемы нет - мы считываем только одну сцену, а не длинную цепочку из всех существующих сцен сразу. Небольшой лаг при нажатии "далее" субъективно лучше, чем ожидание нескольких минут загрузки с белым экраном и надписью "это приложение не отвечает, закрыть?" или прогресс-баром, замершем на 50% по непонятной причине. Хотя масштаб проблемы зависит от количества и размеров ресурсов в конкретной игре (на "hello world" никак не повлияет), но это всё нужно иметь в виду, особенно если планируете расширять игру в будущем дополнительным контентом.
>>39768
Подтверждаю. Самое забавное, что фоновая загрузка может хоть в несколько потоков грузить сцену. Но затем эту огромную сцену движок репарентит в главное дерево, в один поток с мощным пролагом в 0 ФПС. Таким образом весь этот механизм подходит только для мелких и средних игр. Что-то более крупное потребует самодельного менеджера загрузки, который организует очереди загрузки данных в пулы уже имеющихся в действующем дереве нод. Иначе просто нет смысла городить какие-то огороды, они все упрутся в бутылочное горлышко.
>>39758
Ммм... наш слоняра.
> Но, из моего опыта, эта "фоновая" загрузка разочаровывает:
Подтверждаю. Самое забавное, что фоновая загрузка может хоть в несколько потоков грузить сцену. Но затем эту огромную сцену движок репарентит в главное дерево, в один поток с мощным пролагом в 0 ФПС. Таким образом весь этот механизм подходит только для мелких и средних игр. Что-то более крупное потребует самодельного менеджера загрузки, который организует очереди загрузки данных в пулы уже имеющихся в действующем дереве нод. Иначе просто нет смысла городить какие-то огороды, они все упрутся в бутылочное горлышко.
>>39758
> нулевой новичок и тычется в GUI редактора, не читая документацию
Ммм... наш слоняра.
23 Кб, 474x237>>39479
Пени, для твоего случая документация длиной в минут 10 чтения
Пени, для твоего случая документация длиной в минут 10 чтения
>>39810
Движок ничего не репарентит, фоновый загрузчик загружает только ресурс (PackedScene), а что ты с этим ресурсом делать потом будешь - его не касается. Можешь разобрать загруженную сцену на несколько частей (существующими нодами можно оперировать за пределами дерева сцены) и добавлять её в дерево постепенно. Проблема именно в самом процессе загрузки. Вот я сделал шейдером вращающийся логотип и добавил его на экран загрузки, сделанный по документации - в районе 50% (т.е. ДО полной загрузки всех ресурсов) логотип начинает заметно тормозить - и это точно никак не связано с деревом сцены...
И нет, PackedScene в export-полях никак не влияют на добавление сцены в дерево сцены. "Мощный пролаг" возникает только если ты хочешь добавить больше нескольких сотен активных НОД, потому что у них срабатывает _enter_tree, _ready и прочее подобное (особенно у Control-нод много обработчиков, срабатывающих при добавлении в дерево сцены). Ресурсы в нодах типа PackedScene тормозят только считывание с диска (загрузку), но не влияют на добавление сцены в дерево сцены.
Ещё раз, мы рассматриваем 3 независимых ситуации:
1. Маленькая сцена, у которой много отдельных load(String) в скрипте.
2. Маленькая сцена, у которой много отдельных @export var scene: PackedScene.
3. Огромная сцена, у которой несколько тысяч размещённых в дереве сцены нод.
В первом варианте у тебя будет быстрая загрузка, быстрое добавление в дерево сцены и малозаметный лаг при каждом обращении к load(). Если ресурсы мелкие и ты делаешь паузы между каждым load(), лагов может и вообще не быть.
Во втором варианте у тебя будет очень долгая начальная загрузка, потому что движок сразу загружает все ресурсы с диска и что-то с каждым из них делает последовательно, но добавление в дерево сцены будет быстрым и обращение к уже загруженным PackedScene будет быстрее, чем если бы ты использовал load().
В третьем варианте у тебя будет долгая начальная загрузка и долгое добавление в дерево сцены, а дальше всё зависит от того, какие там ноды и что они делают.
Фоновая загрузка в отдельном потоке позволяет продолжать взаимодействие с пользователем через GUI/загрузочный экран/прогресс-бар, пока фоновый поток считывает файлы с диска, поэтому он полезен в любом варианте, но имеет смысл только для действительно больших ресурсов, которые считываются дольше 10 мс.
>>39846
Зависит от конкретных ресурсов. Если у тебя в единственном PackedScene одна Button и одна Label в одном контейнере, то никакой проблемы нет - грузи, как тебе удобнее. А если у тебя два десятка PackedScene с сотнями 3D объектов, тысячами текстур, звуков, материалов, скриптов, кастомных ресурсов для загрузки квестов и т.д., то лучше загружать их по отдельности, а не одним огромным куском, и делать это в фоновом потоке, пока на экране крутится анимация загрузочного экрана.
>эту огромную сцену движок репарентит в главное дерево
Движок ничего не репарентит, фоновый загрузчик загружает только ресурс (PackedScene), а что ты с этим ресурсом делать потом будешь - его не касается. Можешь разобрать загруженную сцену на несколько частей (существующими нодами можно оперировать за пределами дерева сцены) и добавлять её в дерево постепенно. Проблема именно в самом процессе загрузки. Вот я сделал шейдером вращающийся логотип и добавил его на экран загрузки, сделанный по документации - в районе 50% (т.е. ДО полной загрузки всех ресурсов) логотип начинает заметно тормозить - и это точно никак не связано с деревом сцены...
И нет, PackedScene в export-полях никак не влияют на добавление сцены в дерево сцены. "Мощный пролаг" возникает только если ты хочешь добавить больше нескольких сотен активных НОД, потому что у них срабатывает _enter_tree, _ready и прочее подобное (особенно у Control-нод много обработчиков, срабатывающих при добавлении в дерево сцены). Ресурсы в нодах типа PackedScene тормозят только считывание с диска (загрузку), но не влияют на добавление сцены в дерево сцены.
Ещё раз, мы рассматриваем 3 независимых ситуации:
1. Маленькая сцена, у которой много отдельных load(String) в скрипте.
2. Маленькая сцена, у которой много отдельных @export var scene: PackedScene.
3. Огромная сцена, у которой несколько тысяч размещённых в дереве сцены нод.
В первом варианте у тебя будет быстрая загрузка, быстрое добавление в дерево сцены и малозаметный лаг при каждом обращении к load(). Если ресурсы мелкие и ты делаешь паузы между каждым load(), лагов может и вообще не быть.
Во втором варианте у тебя будет очень долгая начальная загрузка, потому что движок сразу загружает все ресурсы с диска и что-то с каждым из них делает последовательно, но добавление в дерево сцены будет быстрым и обращение к уже загруженным PackedScene будет быстрее, чем если бы ты использовал load().
В третьем варианте у тебя будет долгая начальная загрузка и долгое добавление в дерево сцены, а дальше всё зависит от того, какие там ноды и что они делают.
Фоновая загрузка в отдельном потоке позволяет продолжать взаимодействие с пользователем через GUI/загрузочный экран/прогресс-бар, пока фоновый поток считывает файлы с диска, поэтому он полезен в любом варианте, но имеет смысл только для действительно больших ресурсов, которые считываются дольше 10 мс.
>>39846
Зависит от конкретных ресурсов. Если у тебя в единственном PackedScene одна Button и одна Label в одном контейнере, то никакой проблемы нет - грузи, как тебе удобнее. А если у тебя два десятка PackedScene с сотнями 3D объектов, тысячами текстур, звуков, материалов, скриптов, кастомных ресурсов для загрузки квестов и т.д., то лучше загружать их по отдельности, а не одним огромным куском, и делать это в фоновом потоке, пока на экране крутится анимация загрузочного экрана.
>>39810
Движок ничего не репарентит, фоновый загрузчик загружает только ресурс (PackedScene), а что ты с этим ресурсом делать потом будешь - его не касается. Можешь разобрать загруженную сцену на несколько частей (существующими нодами можно оперировать за пределами дерева сцены) и добавлять её в дерево постепенно. Проблема именно в самом процессе загрузки. Вот я сделал шейдером вращающийся логотип и добавил его на экран загрузки, сделанный по документации - в районе 50% (т.е. ДО полной загрузки всех ресурсов) логотип начинает заметно тормозить - и это точно никак не связано с деревом сцены...
И нет, PackedScene в export-полях никак не влияют на добавление сцены в дерево сцены. "Мощный пролаг" возникает только если ты хочешь добавить больше нескольких сотен активных НОД, потому что у них срабатывает _enter_tree, _ready и прочее подобное (особенно у Control-нод много обработчиков, срабатывающих при добавлении в дерево сцены). Ресурсы в нодах типа PackedScene тормозят только считывание с диска (загрузку), но не влияют на добавление сцены в дерево сцены.
Ещё раз, мы рассматриваем 3 независимых ситуации:
1. Маленькая сцена, у которой много отдельных load(String) в скрипте.
2. Маленькая сцена, у которой много отдельных @export var scene: PackedScene.
3. Огромная сцена, у которой несколько тысяч размещённых в дереве сцены нод.
В первом варианте у тебя будет быстрая загрузка, быстрое добавление в дерево сцены и малозаметный лаг при каждом обращении к load(). Если ресурсы мелкие и ты делаешь паузы между каждым load(), лагов может и вообще не быть.
Во втором варианте у тебя будет очень долгая начальная загрузка, потому что движок сразу загружает все ресурсы с диска и что-то с каждым из них делает последовательно, но добавление в дерево сцены будет быстрым и обращение к уже загруженным PackedScene будет быстрее, чем если бы ты использовал load().
В третьем варианте у тебя будет долгая начальная загрузка и долгое добавление в дерево сцены, а дальше всё зависит от того, какие там ноды и что они делают.
Фоновая загрузка в отдельном потоке позволяет продолжать взаимодействие с пользователем через GUI/загрузочный экран/прогресс-бар, пока фоновый поток считывает файлы с диска, поэтому он полезен в любом варианте, но имеет смысл только для действительно больших ресурсов, которые считываются дольше 10 мс.
>>39846
Зависит от конкретных ресурсов. Если у тебя в единственном PackedScene одна Button и одна Label в одном контейнере, то никакой проблемы нет - грузи, как тебе удобнее. А если у тебя два десятка PackedScene с сотнями 3D объектов, тысячами текстур, звуков, материалов, скриптов, кастомных ресурсов для загрузки квестов и т.д., то лучше загружать их по отдельности, а не одним огромным куском, и делать это в фоновом потоке, пока на экране крутится анимация загрузочного экрана.
>эту огромную сцену движок репарентит в главное дерево
Движок ничего не репарентит, фоновый загрузчик загружает только ресурс (PackedScene), а что ты с этим ресурсом делать потом будешь - его не касается. Можешь разобрать загруженную сцену на несколько частей (существующими нодами можно оперировать за пределами дерева сцены) и добавлять её в дерево постепенно. Проблема именно в самом процессе загрузки. Вот я сделал шейдером вращающийся логотип и добавил его на экран загрузки, сделанный по документации - в районе 50% (т.е. ДО полной загрузки всех ресурсов) логотип начинает заметно тормозить - и это точно никак не связано с деревом сцены...
И нет, PackedScene в export-полях никак не влияют на добавление сцены в дерево сцены. "Мощный пролаг" возникает только если ты хочешь добавить больше нескольких сотен активных НОД, потому что у них срабатывает _enter_tree, _ready и прочее подобное (особенно у Control-нод много обработчиков, срабатывающих при добавлении в дерево сцены). Ресурсы в нодах типа PackedScene тормозят только считывание с диска (загрузку), но не влияют на добавление сцены в дерево сцены.
Ещё раз, мы рассматриваем 3 независимых ситуации:
1. Маленькая сцена, у которой много отдельных load(String) в скрипте.
2. Маленькая сцена, у которой много отдельных @export var scene: PackedScene.
3. Огромная сцена, у которой несколько тысяч размещённых в дереве сцены нод.
В первом варианте у тебя будет быстрая загрузка, быстрое добавление в дерево сцены и малозаметный лаг при каждом обращении к load(). Если ресурсы мелкие и ты делаешь паузы между каждым load(), лагов может и вообще не быть.
Во втором варианте у тебя будет очень долгая начальная загрузка, потому что движок сразу загружает все ресурсы с диска и что-то с каждым из них делает последовательно, но добавление в дерево сцены будет быстрым и обращение к уже загруженным PackedScene будет быстрее, чем если бы ты использовал load().
В третьем варианте у тебя будет долгая начальная загрузка и долгое добавление в дерево сцены, а дальше всё зависит от того, какие там ноды и что они делают.
Фоновая загрузка в отдельном потоке позволяет продолжать взаимодействие с пользователем через GUI/загрузочный экран/прогресс-бар, пока фоновый поток считывает файлы с диска, поэтому он полезен в любом варианте, но имеет смысл только для действительно больших ресурсов, которые считываются дольше 10 мс.
>>39846
Зависит от конкретных ресурсов. Если у тебя в единственном PackedScene одна Button и одна Label в одном контейнере, то никакой проблемы нет - грузи, как тебе удобнее. А если у тебя два десятка PackedScene с сотнями 3D объектов, тысячами текстур, звуков, материалов, скриптов, кастомных ресурсов для загрузки квестов и т.д., то лучше загружать их по отдельности, а не одним огромным куском, и делать это в фоновом потоке, пока на экране крутится анимация загрузочного экрана.
Хозяйке на заметку
https://www.youtube.com/watch?v=cpKr1lRUPWA
https://www.youtube.com/watch?v=cpKr1lRUPWA
2 Мб, 1200x872>>39036
Коллизия - капсула, неписи движутся при помощи move_and_slide() и периодически их пути выстраиваются по одной прямой, т.к. иногда их целями являются общие точки (например, места взаимодействия), потому застревают, несмотря на включенный avoiding (который я весь перенастраивал и тестировал с разными параметрами).
Проблемы есть, по вышеописанной причине. У каждого НПС есть список целей к которым он должен подойти (дефолтное патрулирование). Если у двух персонажей будут совпадать две цели между которыми они должны пройти, они обязательно столкнутся и остановятся. Попробовал это исправить с помощью костыля - добавления рейкаста, который двигается влево-вправо и проверяет есть ли на пути другой НПС. Если есть, он ставит себе новую цель в небольшом радиусе (1-3 метра) и идёт к ней, а затем заново строит себе путь к цели из патрулирования. Периодически НПС начинает тупить и даже если достигает новой цели, он не посылает сигнал "target reached", который отвечает за смену цели. Также иногда неписи при столкновении просто отворачиваются друг от друга и их рейкасты с проверкой не могут коснуться коллизии и маршрут к близкой точке не строится.
Спасибо за годный совет, совсем забыл, что такая функция существует!
Просто пробую создать игровой мир, в котором у существ будет интеллект и интересное поведение, а не стоящие на месте болванчики как в современных ААААА-"играх".
Но ты прав, почитаю побольше о навмешах, точках и их генерации.
У меня всё наоборот: сперва я делаю неигрового персонажа, который умеет делать всё, а затем уже сверху к нему идёт скрипт управления, таким образом появляется возможность управления любым существом в игре.
Если мир генерируется, то это будет довольно сложным. Допустим, я сделаю класс "Old_trees", в котором будут находиться ассеты сухих деревьев, и эти деревья должны будут генерироваться не только в прямом положении, но и под углом. Под определённым градусом они будут в положении, когда по ним будет возможно ходить (например, оно было старым, упало на землю). Если во время генерации будет просчитываться угол каждого дерева, каждого кустика и поштучно добавляться Area3D с выбором соответствующей анимации, то генерация уровня будет слишком требовательной, а если у гуманоида прямо из коробки будет умение двигаться по сложному ландшафту - залезать на высоты и пролезать в узкие проходы, использовать специальные стены, по которым можно лазать и т.д. - будет намного быстрее.
Это знаю с тех пор, как поиграл впервые в бладборн в 2016. Там это очень заметно.
Ну почему же? В актуальной версии всё, что связано с навигацией помечено как экспериментальное. Мб что-то придумают разрабы.
Энивей спасибо за комментарий, остаётся только продолжать учиться, изучать движок.
Коллизия - капсула, неписи движутся при помощи move_and_slide() и периодически их пути выстраиваются по одной прямой, т.к. иногда их целями являются общие точки (например, места взаимодействия), потому застревают, несмотря на включенный avoiding (который я весь перенастраивал и тестировал с разными параметрами).
>В случае 2-3 персонажей, проблем от столкновений между ними быть не должно.
Проблемы есть, по вышеописанной причине. У каждого НПС есть список целей к которым он должен подойти (дефолтное патрулирование). Если у двух персонажей будут совпадать две цели между которыми они должны пройти, они обязательно столкнутся и остановятся. Попробовал это исправить с помощью костыля - добавления рейкаста, который двигается влево-вправо и проверяет есть ли на пути другой НПС. Если есть, он ставит себе новую цель в небольшом радиусе (1-3 метра) и идёт к ней, а затем заново строит себе путь к цели из патрулирования. Периодически НПС начинает тупить и даже если достигает новой цели, он не посылает сигнал "target reached", который отвечает за смену цели. Также иногда неписи при столкновении просто отворачиваются друг от друга и их рейкасты с проверкой не могут коснуться коллизии и маршрут к близкой точке не строится.
>использовать коэффициент проходимости для выбора пути
Спасибо за годный совет, совсем забыл, что такая функция существует!
>игра имеет некое нестандартное движение по сложной местности
Просто пробую создать игровой мир, в котором у существ будет интеллект и интересное поведение, а не стоящие на месте болванчики как в современных ААААА-"играх".
Но ты прав, почитаю побольше о навмешах, точках и их генерации.
>рекомендую начать с игрового персонажа
У меня всё наоборот: сперва я делаю неигрового персонажа, который умеет делать всё, а затем уже сверху к нему идёт скрипт управления, таким образом появляется возможность управления любым существом в игре.
>типа Area3D вокруг бревна
Если мир генерируется, то это будет довольно сложным. Допустим, я сделаю класс "Old_trees", в котором будут находиться ассеты сухих деревьев, и эти деревья должны будут генерироваться не только в прямом положении, но и под углом. Под определённым градусом они будут в положении, когда по ним будет возможно ходить (например, оно было старым, упало на землю). Если во время генерации будет просчитываться угол каждого дерева, каждого кустика и поштучно добавляться Area3D с выбором соответствующей анимации, то генерация уровня будет слишком требовательной, а если у гуманоида прямо из коробки будет умение двигаться по сложному ландшафту - залезать на высоты и пролезать в узкие проходы, использовать специальные стены, по которым можно лазать и т.д. - будет намного быстрее.
>моделька идёт за физической коллизией
Это знаю с тех пор, как поиграл впервые в бладборн в 2016. Там это очень заметно.
>ждать чуда от новых версий движка в плане навигации персонажей бесполезно
Ну почему же? В актуальной версии всё, что связано с навигацией помечено как экспериментальное. Мб что-то придумают разрабы.
Энивей спасибо за комментарий, остаётся только продолжать учиться, изучать движок.
2 Мб, 1200x872>>39036
Коллизия - капсула, неписи движутся при помощи move_and_slide() и периодически их пути выстраиваются по одной прямой, т.к. иногда их целями являются общие точки (например, места взаимодействия), потому застревают, несмотря на включенный avoiding (который я весь перенастраивал и тестировал с разными параметрами).
Проблемы есть, по вышеописанной причине. У каждого НПС есть список целей к которым он должен подойти (дефолтное патрулирование). Если у двух персонажей будут совпадать две цели между которыми они должны пройти, они обязательно столкнутся и остановятся. Попробовал это исправить с помощью костыля - добавления рейкаста, который двигается влево-вправо и проверяет есть ли на пути другой НПС. Если есть, он ставит себе новую цель в небольшом радиусе (1-3 метра) и идёт к ней, а затем заново строит себе путь к цели из патрулирования. Периодически НПС начинает тупить и даже если достигает новой цели, он не посылает сигнал "target reached", который отвечает за смену цели. Также иногда неписи при столкновении просто отворачиваются друг от друга и их рейкасты с проверкой не могут коснуться коллизии и маршрут к близкой точке не строится.
Спасибо за годный совет, совсем забыл, что такая функция существует!
Просто пробую создать игровой мир, в котором у существ будет интеллект и интересное поведение, а не стоящие на месте болванчики как в современных ААААА-"играх".
Но ты прав, почитаю побольше о навмешах, точках и их генерации.
У меня всё наоборот: сперва я делаю неигрового персонажа, который умеет делать всё, а затем уже сверху к нему идёт скрипт управления, таким образом появляется возможность управления любым существом в игре.
Если мир генерируется, то это будет довольно сложным. Допустим, я сделаю класс "Old_trees", в котором будут находиться ассеты сухих деревьев, и эти деревья должны будут генерироваться не только в прямом положении, но и под углом. Под определённым градусом они будут в положении, когда по ним будет возможно ходить (например, оно было старым, упало на землю). Если во время генерации будет просчитываться угол каждого дерева, каждого кустика и поштучно добавляться Area3D с выбором соответствующей анимации, то генерация уровня будет слишком требовательной, а если у гуманоида прямо из коробки будет умение двигаться по сложному ландшафту - залезать на высоты и пролезать в узкие проходы, использовать специальные стены, по которым можно лазать и т.д. - будет намного быстрее.
Это знаю с тех пор, как поиграл впервые в бладборн в 2016. Там это очень заметно.
Ну почему же? В актуальной версии всё, что связано с навигацией помечено как экспериментальное. Мб что-то придумают разрабы.
Энивей спасибо за комментарий, остаётся только продолжать учиться, изучать движок.
Коллизия - капсула, неписи движутся при помощи move_and_slide() и периодически их пути выстраиваются по одной прямой, т.к. иногда их целями являются общие точки (например, места взаимодействия), потому застревают, несмотря на включенный avoiding (который я весь перенастраивал и тестировал с разными параметрами).
>В случае 2-3 персонажей, проблем от столкновений между ними быть не должно.
Проблемы есть, по вышеописанной причине. У каждого НПС есть список целей к которым он должен подойти (дефолтное патрулирование). Если у двух персонажей будут совпадать две цели между которыми они должны пройти, они обязательно столкнутся и остановятся. Попробовал это исправить с помощью костыля - добавления рейкаста, который двигается влево-вправо и проверяет есть ли на пути другой НПС. Если есть, он ставит себе новую цель в небольшом радиусе (1-3 метра) и идёт к ней, а затем заново строит себе путь к цели из патрулирования. Периодически НПС начинает тупить и даже если достигает новой цели, он не посылает сигнал "target reached", который отвечает за смену цели. Также иногда неписи при столкновении просто отворачиваются друг от друга и их рейкасты с проверкой не могут коснуться коллизии и маршрут к близкой точке не строится.
>использовать коэффициент проходимости для выбора пути
Спасибо за годный совет, совсем забыл, что такая функция существует!
>игра имеет некое нестандартное движение по сложной местности
Просто пробую создать игровой мир, в котором у существ будет интеллект и интересное поведение, а не стоящие на месте болванчики как в современных ААААА-"играх".
Но ты прав, почитаю побольше о навмешах, точках и их генерации.
>рекомендую начать с игрового персонажа
У меня всё наоборот: сперва я делаю неигрового персонажа, который умеет делать всё, а затем уже сверху к нему идёт скрипт управления, таким образом появляется возможность управления любым существом в игре.
>типа Area3D вокруг бревна
Если мир генерируется, то это будет довольно сложным. Допустим, я сделаю класс "Old_trees", в котором будут находиться ассеты сухих деревьев, и эти деревья должны будут генерироваться не только в прямом положении, но и под углом. Под определённым градусом они будут в положении, когда по ним будет возможно ходить (например, оно было старым, упало на землю). Если во время генерации будет просчитываться угол каждого дерева, каждого кустика и поштучно добавляться Area3D с выбором соответствующей анимации, то генерация уровня будет слишком требовательной, а если у гуманоида прямо из коробки будет умение двигаться по сложному ландшафту - залезать на высоты и пролезать в узкие проходы, использовать специальные стены, по которым можно лазать и т.д. - будет намного быстрее.
>моделька идёт за физической коллизией
Это знаю с тех пор, как поиграл впервые в бладборн в 2016. Там это очень заметно.
>ждать чуда от новых версий движка в плане навигации персонажей бесполезно
Ну почему же? В актуальной версии всё, что связано с навигацией помечено как экспериментальное. Мб что-то придумают разрабы.
Энивей спасибо за комментарий, остаётся только продолжать учиться, изучать движок.
Поясните за наследование. Есть сцена-класс Enemy, от неё наследуется подкласс Goblin. Enemy в своём _ready() устанавливает базовые параметры (типа координат, здоровья и т.п.), я хочу чтобы Goblin в своём _ready() дополнительно подтягивал соответствующий спрайт, и вся эта конструкция занимала минимум памяти. Т.е. в идеале Goblin существует на диске только в виде скрипта, и при инициализации тянет из памяти сцену Enemy и достраивает её своим кодом.
В документации по этой теме написано довольно странно, правильно ли я понимаю что вызвать в goblin.gd
func _ready():
-- super._ready()
будет достаточно?
В документации по этой теме написано довольно странно, правильно ли я понимаю что вызвать в goblin.gd
func _ready():
-- super._ready()
будет достаточно?
1 Мб, 1280x720Только что узнал что Юлик друг хованского друг меддисона имеет второй канал на котором делает игры про сисястых котов лудоманов на годоте.
https://www.youtube.com/watch?v=FwmBl54dKgQ
https://www.youtube.com/watch?v=FwmBl54dKgQ
>>40126
Я просто не использую наследование - все скатывается в кашу. Использую композицию.
Это тебе фраза-триггер, чтобы графоман из постов выше тебе портянку-пояснение написал.
Я просто не использую наследование - все скатывается в кашу. Использую композицию.
Это тебе фраза-триггер, чтобы графоман из постов выше тебе портянку-пояснение написал.
>>40146
Хуясе, ебать! Заявочка на победу.
Хуясе, ебать! Заявочка на победу.
>>40047
По моему опыту, могут помочь такие действия:
1. Переходить к следующей немного пораньше:
2. Идти не до точки, а до точки + случайный сдвиг:
3. Поворачивать вектор движения к точке плавно:
Суммарно выйдет что NPC ходят по-разному.
А, я понял. См. пункты 1-2 выше, должно помочь.
Не пробовал сделать шаг назад и подождать?
Кто этот сигнал посылать должен? Твой же код?
Почитай про artificial life, life simulation, virtual pets, RL:
https://en.wikipedia.org/wiki/Artificial_life
https://en.wikipedia.org/wiki/Life_simulation_game
https://en.wikipedia.org/wiki/Virtual_pet
https://en.wikipedia.org/wiki/Reinforcement_learning
Рекомендую попробовать поиграть в Creatures:
https://en.wikipedia.org/wiki/Creatures_(video_game_series)
https://store.steampowered.com/app/1659050/
Тоже этой темой интересуюсь уже много лет...
Речь о тестировании твоих персонажей.
(N)PC условно состоит из следующих частей:
1. Физическая модель в физическом мире.
2. 3D моделька с анимациями (или 2D спрайты).
3. Контроллер - отдаёт атомарные команды 1 и 2.
4. Планировщик - строит порядок команд для 3.
4.1. Поиск пути (astar) - планировщик маршрутов.
4.2. State machine, decision tree, utility AI, GOAP, RL...
4.3. Игрок способен играть роль планировщика.
Вот сначала сделай 1-3 + 4.3, потом уже 4.1±4.2.
Но она происходит один раз, перед запуском игры.
А с чего ты вдруг взял, что это будет быстрее?
Смотри, у тебя три задачи:
1. Построить игровую карту/мир:
- вручную, сэкономив время загрузки и кадра;
- процедурно + оффлайн, тратя время загрузки;
- процедурно + онлайн, тратя мс каждого кадра.
2. Найти оптимальный путь через неё:
- заранее (оффлайн), сэкономив время кадра;
- онлайн, тратя драгоценные мс каждого кадра.
3. Осуществить движение по пути:
- изменить положение лишь в момент отображения;
- онлайн, анимируя 3D меш в поле обзора камеры.
Что тебе важнее? Всегда будут какие-то траты.
Подробные онлайн симуляции всегда затратны...
Это предупреждение, что API может измениться:
- могут изменить аргументы и имена функций;
- могут изменить интерфейс и поведение классов;
- могут удалить функции, классы, даже всю систему.
Т.е. "experimental" == "юзайте на свой страх и риск".
>выстраиваются по одной прямой
По моему опыту, могут помочь такие действия:
1. Переходить к следующей немного пораньше:
>if position.distance_to(point) < (random() + 1):
>_ point = path_points.pop_last()
2. Идти не до точки, а до точки + случайный сдвиг:
>point += Vector3(random() - 0.5, 0.0, random() - 0.5)
>direction = global_position.direction_to(point)
3. Поворачивать вектор движения к точке плавно:
>velocity = velocity.slerp(direction × speed, 0.01)
Суммарно выйдет что NPC ходят по-разному.
>две цели между которыми они должны пройти
А, я понял. См. пункты 1-2 выше, должно помочь.
>ставит себе новую цель в небольшом радиусе
Не пробовал сделать шаг назад и подождать?
>не посылает сигнал "target reached"
Кто этот сигнал посылать должен? Твой же код?
>у существ будет интеллект и интересное поведение
Почитай про artificial life, life simulation, virtual pets, RL:
https://en.wikipedia.org/wiki/Artificial_life
https://en.wikipedia.org/wiki/Life_simulation_game
https://en.wikipedia.org/wiki/Virtual_pet
https://en.wikipedia.org/wiki/Reinforcement_learning
Рекомендую попробовать поиграть в Creatures:
https://en.wikipedia.org/wiki/Creatures_(video_game_series)
https://store.steampowered.com/app/1659050/
Тоже этой темой интересуюсь уже много лет...
>сперва я делаю неигрового персонажа
Речь о тестировании твоих персонажей.
(N)PC условно состоит из следующих частей:
1. Физическая модель в физическом мире.
2. 3D моделька с анимациями (или 2D спрайты).
3. Контроллер - отдаёт атомарные команды 1 и 2.
4. Планировщик - строит порядок команд для 3.
4.1. Поиск пути (astar) - планировщик маршрутов.
4.2. State machine, decision tree, utility AI, GOAP, RL...
4.3. Игрок способен играть роль планировщика.
Вот сначала сделай 1-3 + 4.3, потом уже 4.1±4.2.
>генерация уровня будет слишком требовательной
Но она происходит один раз, перед запуском игры.
>если у гуманоида... будет умение... намного быстрее
А с чего ты вдруг взял, что это будет быстрее?
Смотри, у тебя три задачи:
1. Построить игровую карту/мир:
- вручную, сэкономив время загрузки и кадра;
- процедурно + оффлайн, тратя время загрузки;
- процедурно + онлайн, тратя мс каждого кадра.
2. Найти оптимальный путь через неё:
- заранее (оффлайн), сэкономив время кадра;
- онлайн, тратя драгоценные мс каждого кадра.
3. Осуществить движение по пути:
- изменить положение лишь в момент отображения;
- онлайн, анимируя 3D меш в поле обзора камеры.
Что тебе важнее? Всегда будут какие-то траты.
Подробные онлайн симуляции всегда затратны...
>помечено как экспериментальное
Это предупреждение, что API может измениться:
- могут изменить аргументы и имена функций;
- могут изменить интерфейс и поведение классов;
- могут удалить функции, классы, даже всю систему.
Т.е. "experimental" == "юзайте на свой страх и риск".
>>40047
По моему опыту, могут помочь такие действия:
1. Переходить к следующей немного пораньше:
2. Идти не до точки, а до точки + случайный сдвиг:
3. Поворачивать вектор движения к точке плавно:
Суммарно выйдет что NPC ходят по-разному.
А, я понял. См. пункты 1-2 выше, должно помочь.
Не пробовал сделать шаг назад и подождать?
Кто этот сигнал посылать должен? Твой же код?
Почитай про artificial life, life simulation, virtual pets, RL:
https://en.wikipedia.org/wiki/Artificial_life
https://en.wikipedia.org/wiki/Life_simulation_game
https://en.wikipedia.org/wiki/Virtual_pet
https://en.wikipedia.org/wiki/Reinforcement_learning
Рекомендую попробовать поиграть в Creatures:
https://en.wikipedia.org/wiki/Creatures_(video_game_series)
https://store.steampowered.com/app/1659050/
Тоже этой темой интересуюсь уже много лет...
Речь о тестировании твоих персонажей.
(N)PC условно состоит из следующих частей:
1. Физическая модель в физическом мире.
2. 3D моделька с анимациями (или 2D спрайты).
3. Контроллер - отдаёт атомарные команды 1 и 2.
4. Планировщик - строит порядок команд для 3.
4.1. Поиск пути (astar) - планировщик маршрутов.
4.2. State machine, decision tree, utility AI, GOAP, RL...
4.3. Игрок способен играть роль планировщика.
Вот сначала сделай 1-3 + 4.3, потом уже 4.1±4.2.
Но она происходит один раз, перед запуском игры.
А с чего ты вдруг взял, что это будет быстрее?
Смотри, у тебя три задачи:
1. Построить игровую карту/мир:
- вручную, сэкономив время загрузки и кадра;
- процедурно + оффлайн, тратя время загрузки;
- процедурно + онлайн, тратя мс каждого кадра.
2. Найти оптимальный путь через неё:
- заранее (оффлайн), сэкономив время кадра;
- онлайн, тратя драгоценные мс каждого кадра.
3. Осуществить движение по пути:
- изменить положение лишь в момент отображения;
- онлайн, анимируя 3D меш в поле обзора камеры.
Что тебе важнее? Всегда будут какие-то траты.
Подробные онлайн симуляции всегда затратны...
Это предупреждение, что API может измениться:
- могут изменить аргументы и имена функций;
- могут изменить интерфейс и поведение классов;
- могут удалить функции, классы, даже всю систему.
Т.е. "experimental" == "юзайте на свой страх и риск".
>выстраиваются по одной прямой
По моему опыту, могут помочь такие действия:
1. Переходить к следующей немного пораньше:
>if position.distance_to(point) < (random() + 1):
>_ point = path_points.pop_last()
2. Идти не до точки, а до точки + случайный сдвиг:
>point += Vector3(random() - 0.5, 0.0, random() - 0.5)
>direction = global_position.direction_to(point)
3. Поворачивать вектор движения к точке плавно:
>velocity = velocity.slerp(direction × speed, 0.01)
Суммарно выйдет что NPC ходят по-разному.
>две цели между которыми они должны пройти
А, я понял. См. пункты 1-2 выше, должно помочь.
>ставит себе новую цель в небольшом радиусе
Не пробовал сделать шаг назад и подождать?
>не посылает сигнал "target reached"
Кто этот сигнал посылать должен? Твой же код?
>у существ будет интеллект и интересное поведение
Почитай про artificial life, life simulation, virtual pets, RL:
https://en.wikipedia.org/wiki/Artificial_life
https://en.wikipedia.org/wiki/Life_simulation_game
https://en.wikipedia.org/wiki/Virtual_pet
https://en.wikipedia.org/wiki/Reinforcement_learning
Рекомендую попробовать поиграть в Creatures:
https://en.wikipedia.org/wiki/Creatures_(video_game_series)
https://store.steampowered.com/app/1659050/
Тоже этой темой интересуюсь уже много лет...
>сперва я делаю неигрового персонажа
Речь о тестировании твоих персонажей.
(N)PC условно состоит из следующих частей:
1. Физическая модель в физическом мире.
2. 3D моделька с анимациями (или 2D спрайты).
3. Контроллер - отдаёт атомарные команды 1 и 2.
4. Планировщик - строит порядок команд для 3.
4.1. Поиск пути (astar) - планировщик маршрутов.
4.2. State machine, decision tree, utility AI, GOAP, RL...
4.3. Игрок способен играть роль планировщика.
Вот сначала сделай 1-3 + 4.3, потом уже 4.1±4.2.
>генерация уровня будет слишком требовательной
Но она происходит один раз, перед запуском игры.
>если у гуманоида... будет умение... намного быстрее
А с чего ты вдруг взял, что это будет быстрее?
Смотри, у тебя три задачи:
1. Построить игровую карту/мир:
- вручную, сэкономив время загрузки и кадра;
- процедурно + оффлайн, тратя время загрузки;
- процедурно + онлайн, тратя мс каждого кадра.
2. Найти оптимальный путь через неё:
- заранее (оффлайн), сэкономив время кадра;
- онлайн, тратя драгоценные мс каждого кадра.
3. Осуществить движение по пути:
- изменить положение лишь в момент отображения;
- онлайн, анимируя 3D меш в поле обзора камеры.
Что тебе важнее? Всегда будут какие-то траты.
Подробные онлайн симуляции всегда затратны...
>помечено как экспериментальное
Это предупреждение, что API может измениться:
- могут изменить аргументы и имена функций;
- могут изменить интерфейс и поведение классов;
- могут удалить функции, классы, даже всю систему.
Т.е. "experimental" == "юзайте на свой страх и риск".
>>40126
Зачем? Ты разве не используешь @export var...?
Ты не о том беспокоишься... Памяти сейчас дофига. Конкретно Godot не может похвастаться бережным использованием памяти - у нас тут любая мелочь резервирует кучу "лишних" байт в RAM... Сцены могут показаться жирными из-за текстового формата .tscn, однако, в экспорте будут сжатые бинарные .scn. Т.е. беспокоиться из-за сцен на диске и @export не стоит.
К тому же загрузка сцен из tscn оптимизирована по производительности, а твой личный код на GDScript, записанный в _ready(), тормозит инициализацию (конкретнее - первое добавление ноды в дерево).
Если ты зачем-то хочешь максимально сэкономить, фокусируйся на медиафайлах: текстуры, звуки и т.д. Сжимать без потерь их очень сложно, поэтому все компактные на диске игры просто выбрасывают необязательный контент. Есть, конечно, вариант с процедурной генерацией, но это опять же не лучшее решение в рамках игр на Godot/GDScript (медленно).
Честно - не помню, но вроде бы должно работать.
>>40136
Он там на байты дрочит, т.е. "каша" в любом случае получится, потому что он собирается все константы хардкодить в _ready() вместо @export var... + .tscn. Композиция не поможет разобрать эту кашу, а лишь перенесёт комочки каши с одного места в другое...
Да тут нечего пояснять. Просто не изобретайте свои "гениальные" велосипеды, когда есть встроенное в выбранный инструмент решение. Это решение тут существует не просто так, а потому что помогает. Изобретателям велосипедов лучше спускаться на низкоуровневые инструменты (игра с нуля на C).
>_ready() устанавливает базовые параметры
Зачем? Ты разве не используешь @export var...?
>конструкция занимала минимум памяти
Ты не о том беспокоишься... Памяти сейчас дофига. Конкретно Godot не может похвастаться бережным использованием памяти - у нас тут любая мелочь резервирует кучу "лишних" байт в RAM... Сцены могут показаться жирными из-за текстового формата .tscn, однако, в экспорте будут сжатые бинарные .scn. Т.е. беспокоиться из-за сцен на диске и @export не стоит.
К тому же загрузка сцен из tscn оптимизирована по производительности, а твой личный код на GDScript, записанный в _ready(), тормозит инициализацию (конкретнее - первое добавление ноды в дерево).
Если ты зачем-то хочешь максимально сэкономить, фокусируйся на медиафайлах: текстуры, звуки и т.д. Сжимать без потерь их очень сложно, поэтому все компактные на диске игры просто выбрасывают необязательный контент. Есть, конечно, вариант с процедурной генерацией, но это опять же не лучшее решение в рамках игр на Godot/GDScript (медленно).
>super._ready()
>будет достаточно?
Честно - не помню, но вроде бы должно работать.
>>40136
>все скатывается в кашу
Он там на байты дрочит, т.е. "каша" в любом случае получится, потому что он собирается все константы хардкодить в _ready() вместо @export var... + .tscn. Композиция не поможет разобрать эту кашу, а лишь перенесёт комочки каши с одного места в другое...
>портянку-пояснение написал
Да тут нечего пояснять. Просто не изобретайте свои "гениальные" велосипеды, когда есть встроенное в выбранный инструмент решение. Это решение тут существует не просто так, а потому что помогает. Изобретателям велосипедов лучше спускаться на низкоуровневые инструменты (игра с нуля на C).