Pull to refresh

Comments 1

Хватит мыслить типичными шаблонами.
_process - это не игровой цикл. Это игровой кадр, при том кадр отрисовки. Не надо забивать в него все что можно. Для ввода есть _input* асинхронные функции.
_physics_process - это кадр физики, и завязан на физическом интервале, используй его для движения и логики, если асинхронно это сделать не возможно.

Не надо задавать имя Main. Годот асинхронен и каждый объект есть автономная подсцена. Не надо пытаться выделить God Object который будет отвечать за все.

Контроль управления написан ужасно и используется старая практика, которой придерживались новички еще со времён godot 2

У игры есть методы Input.get_action_strength()
Он возвращает числе в диапазоне 0.0-1.0 в зависимости от силы нажатия. (работает как со стиками, так и с кнопками)
А есть так же Input.get_vector
Который возвращает 2Д вектор. В него ты передаешь силы нажатия left, right, forward, back.
В итоге в место лютой писанины, весь твой код уместится в 5-8 строк.
А не бессмысленная писанина match конструкций и if else блоков.

Вот решение большей части твоего кода:

var input_vector := Input.get_vector(
  Input.get_action_streangth("LEFT"),
  Input.get_action_streangth("RIGHT"),
  Input.get_action_streangth("FORWARD"),
  Input.get_action_streangth("BACK")
)
transform = transform.look_at(transform.origin + input_vector)

В офф документации говорится, что не надо вращать объекты в ручную в 3Д. Есть методы look_at, всегда можно использовать вспомогательный узел и что-то еще, чем полотно векторов вращения, которые работают по принципу эйлера. rotation и rotation_degrees нужны в основном для работы в инспекторе, логику же писать через базисы и transform лучше.

Так же весь интерфейс написан не правильно.
Твой интерфейс не учитывает адаптивность мониторов. Ты не использовал якоря, хотя они есть в любом объекте типа Control. UI лучше вынести в отдельный CavansLayer узел, а не вставлять их в 3Д узел как дочерний элемент.

Логика персонажа в идеале должна быть внутри отдельного объекта, а лучше в KinematicBody. Реализовывается логика в 10-20 строчек, полностью кинематическое тело с физикой, столкновениями и т.д.

Я это веду все к тому, что вы своим примером подаете ОЧЕНЬ ПЛОХУЮ ПРАКТИКУ!
А потом я каждый день объясняю людям, что так делать не надо. Каждый день люди совершают одни и те же ошибки, не придерживаются хорошим практикам, которые описаны в официальной документации. Смотрят устаревшие гайды от людей, которые не разобрались в инструменте и учат этому других.

Советую ознакомится с этим каналом. И видео которое откроет глаза на более лучшие практики.
(Гайд писался под более старую версию движка, так что там может не быть get_vector)


Александр @thenonsense

Архитектор игровых механик

Архитектором игровых механик если честно гайд и не пахнет. Зато тонна антипаттернов. Вы лучше пишите гайды связанные с дизайном игровых механик и то, с чем связана ваша профессия. А кодинг, оптимизацию оставьте специалистам.
Вы не представляете сколько раз я людям объяснял, что так делать не надо. Но каждый день в дискорд и другие группы влетают люди, что начитались и насмотрелись гайдов от соочесетвенников, особенно те что перелезли с Unity и тянут от туда даже стиль написания кода.

Sign up to leave a comment.

Articles