Как лучше спавнить врагов в юнити?

Question

[Gromer-Top]

Хотелось бы узнать, как лучше заспавнить врагов в игре, например, в каком-нибудь экшн приключенческом платформере(намёк на известную игру, не знаю можно ли здесь писать название) . Скорее всего враги должны появляться один раз и много однотипных. Лучше расставить вручную или спавнить скриптов перед заходом на локацию?

Answer 1

[DrRen7]

Тут правильного действия не будет все зависит от конкретной реализации. Обычно во время загрузки через порождающий паттерн спавним минимальное количество врагов и добавляем их в пулл и переиспользуем, если игра линейная и мы точно встретим всех врагов то можно всех заспавнить и выключить. Ну а стоит ли сохранять врагов на сцене можно, но если будешь спавнить ещё врагов то и смысла нету, принято что ты начинаешь с пустой сцены имея геометрию и триггеры конкретной сцены(обычно даже нет персонажа) но есть все для создания. Ты не знаешь что будет перенесено из другой сцены

Comments

[Gromer-Top]

Тут вопрос в плане оптимизации, есть ли разница, когда префаб спавнишь, или когда расставляешь.

[DrRen7]

Gromer-Top,
Instantiate и Destroy это достаточно дорогие операции, но при загрузке это не особо заметно.
Лучше, что б на сцене ничего кроме карты не было а там уже все зависит от потребностей можно или сразу всех в загрузке заспавнить или только начальных и тд.

[Gromer-Top]

DrRen7, интересно узнать ваше мнение, лучше разбивать проект на маленькие скрипты, или в больших всё хранить?

[DrRen7]

Gromer-Top,
Все зависит от абстракции. Вот допустим реализация ты говоришь персонаж.иди тебе не интересно что за персонаж и как он ходит, главное что ты знаешь что есть какой то объект и у него есть метод передвижения, но для всего этого нужен свой класс. Те отдельно все то что говорит идти потом сам персонаж что ходит потом метод для хождения и тд. Минусы в том что код становится сложнее читать, нужно думать об архитектуре зависимостях интерфейсах и тд. Плюсы это легко искать баги, сложнее накосячить потому как абстракция меняется реже чем реализация. Если же мы смотрим на GOD класс где есть все оно как бы все хорошо пока ты а потом через неделю возвращается и ничего уже не понимаешь, плюс бывает ошибка ну какая то логическая и код до нее пойдет и дальше ничего делать не будет.

Вот пока учиться самый оптимальный вариант - это все что для одного объекта использовать в 1 скрипте только сразу стоит разделять логику и графику, ну как пример разделять аниматор и контроллер. А так пишешь пробудешь все работает делаешь рефакторинг

[Gromer-Top]

DrRen7, понял, спасибо. Уже переписал Player Controller и вынес Animation Controller. Намного легче стало. Вопрос возник из-за проблемного прыжка

[DrRen7]

Gromer-Top,
Лай хак с прыжками это отдельный расчет вектора горизонтального движения и вертикальной скорости
по сути все получиться так

Vector3 playerMove = (_moveDir*_playerSpeed+Vector3.up*_fallSpeed)*Time.deltaTime;
//ну это пример в вакууме _moveDir - это Vector3 transform.forward*input.x+transform.right*input.y
//ну а _fallSpeed - это float что ты там рассчитываешь по формуле при + это прыжок минус падение
// далее это все идет в RB или CC, в Rb не надо домножать на Time.deltaTime и надо смотреть на rb.velocity.y

[Gromer-Top]

DrRen7, я не уверен, но судя по transform.right пример из 3D?

Я пробовал просто через AddForce, так как в простом сайд-скролинг проекте не вижу смысла заморачиваться с прыжком(на начальном этапе как минимум)