Создание сценариев для поведения каждого объекта вместо записи всего в теле сценария объекта - PullRequest
0 голосов
/ 23 апреля 2019

В моем примере сцены есть два игровых объекта.Оба должны постоянно вращаться с определенной скоростью на своем локальном пространстве.Это просто монеты , цель которых собирать игрок.Вместо того чтобы писать скрипт вращения внутри каждого метода Update () , я создал скрипт под названием Rotator, который заставляет объект, к которому он прикреплен, вращаться.

Я прикрепил компонент Rotator к каждому объекту, и он работает просто отлично.Теперь у меня есть два игровых объекта с компонентом Rotator , который заставит их вращаться.

Это класс Rotator :

using UnityEngine;

public class Rotator : MonoBehaviour
{
    [SerializeField][Range(5, 10)]
    private int _rotationSpeed = 5;

    [SerializeField]
    private float _xAxes = 0;
    [SerializeField]
    private float _yAxes = 0;
    [SerializeField]
    private float _zAxes = 0;

    void Update()
    {
        transform.Rotate(new Vector3(_xAxes, _yAxes, _zAxes) * _rotationSpeed * Time.deltaTime);
    }
}

Я думаю, что таким образом процесс создания моих игровых объектов намного проще и модульный , чем написание того же кода выше внутри каждого элемента, который должен вращаться.

Мой вопрос: будет ли этоповлиять на производительность?Разве плохая идея разбивать поведение на маленькие части или компоненты, а затем добавлять их к каждому игровому объекту, который их требует?Или лучше, в случае простого поворота, написать эту строку кода непосредственно внутри одного скрипта игрового объекта?

Например, у меня теперь есть другой игровой объект с именем Player , которыйнужно вращаться и на себя.К этому игровому объекту уже прикреплен еще один скрипт под названием PlayerController , который обрабатывает движения игрока с клавиатуры.Я могу написать эту часть ...

        transform.Rotate(new Vector3(_xAxes, _yAxes, _zAxes) * _rotationSpeed * Time.deltaTime);

... внутри метода updateC (PlayerController) или, как мне кажется, лучше, присоединить к нему скрипт Rotator.В последнем случае у меня будет игровой объект с двумя компонентами:

  • PlayerController
  • Rotator

Конечно, это всего лишь пример,Я не хочу, чтобы мой игрок продолжал крутиться на самом деле, просто чтобы объяснить мою точку зрения.

Итак, в конце мне нужно понять, является ли это хорошей практикой , даже если небольшая строка кода, подобная ротации, стоит создать компонент ?И я имею в виду поведение, которое требуется более чем одному объекту, конечно, я знаю, что, если это единственный случай, имеет смысл написать его непосредственно в сценарии, который уже присоединен к игровому объекту ввопрос.

Длинный пост, надеюсь, я был достаточно ясен.Спасибо всем!

Ответы [ 2 ]

0 голосов
/ 23 апреля 2019

То, как вы это делаете, это то, как это должно быть сделано. Идея единства заключается в использовании небольших модульных компонентов, которые можно использовать повторно. Однако наличие множества функций обновления может повлиять на производительность, особенно если вы используете Mono, а не IL2CPP.

Но есть несколько решений для этого.

  • Используйте IL2CPP для удаления "виртуального" уровня вызовов между C # (ваш код) и c ++ стороной (код движка).
  • Напишите менеджер поведения, который обновит все ваши скрипты со стороны c #.
  • Посмотрите на систему Entity Component System и переберите все, что нужно повернуть в одной «функции обновления».

На самом деле мы выпустили игру, в которой вращающиеся кристаллы влияли на производительность процессора. В конце мы вычислили значение LocalRotation только один раз за кадр и распределили его по всем кристаллам.

0 голосов
/ 23 апреля 2019

Это действительно зависит от размера игр и количества прилагаемых скриптов.Если это большая игра с десятками длинных сценариев, вы должны балансировать между организацией вашей игры и производительностью, так как оба важны.Например, лучше вызывать метод 1000 раз внутри одного метода обновления, чем 1000 отдельных сценариев с одним методом обновленияВ вашем случае, поскольку это просто и вращение одинаково для обоих объектов, лучше создать общий отдельный скрипт, как у вас.Если вам нужно какое-либо изменение в их ротации, вы можете изменить его только один раз, плюс никаких существенных затрат на производительность.

...