Pull to refresh

Comments 12

Внутри создадим простой дженерик метод расширения, который будет оборачивать любой инстанс в массив

Господи, сколько же вас еще придет из кровавого enterprise-а в мой любимый, но все более и более тормозящий геймдев…
Если хотите сделать что-то сложнее одного бегающего человечка, не нужно делать так. С таким количеством аллокаций производительность убита на корню.
Какие именно аллокации, вернее под какие структуры, под которые бы проводились аллокации, по вашему мнению должы убить производительность?
аллокации в апдейт методах
//Обрабатываем клик левой кнопки мыши
       if (Input.GetMouseButtonDown(0))
       {
           //Берем точку по которой игрок нажал и отправляем всем компонентам уведомление
           var hit = GetMouseHit();
           Events.PublishAsync("poittogound", new PointOnGroundEventData { Sender = this, Point = hit.point });
       }


 protected override void OnUpdate()
   {
       //Передача состояния по позиции агента
       if (agent.remainingDistance > agent.stoppingDistance)
       {
           Events.Publish("agentmoved",
               new AgentMoveEventData { Sender = this, DesiredVelocity = agent.desiredVelocity });
       }
       else
       {
           Events.Publish("agentmoved",
               new AgentMoveEventData { Sender = this, DesiredVelocity = Vector3.zero });
       }
   }


Массивы
protected override Task[] OnUpdateAsync()
{
   //Передача состояния по позиции агента
   if (agent.remainingDistance > agent.stoppingDistance)
   {
       return new Task[] { Events.PublishAsync("agentmoved",
           new AgentMoveEventData { Sender = this, DesiredVelocity = agent.desiredVelocity }) };
   }
   else
   {
       return new Task[] { Events.PublishAsync("agentmoved",
           new AgentMoveEventData { Sender = this, DesiredVelocity = Vector3.zero }) };
   }
}


Также, то что уже сказали до меня: link

И это только для управления одним персонажем. А если в у нас будет в сцене 5-10-20 объектов построенных на этой системе?

Возможно для десктоп платформ это еще может работать в небольших инди проектах, то для мобильных проектов это недопустимо. На проектах которых мне довелось работать, количество аллокаций в кадр было в районе 500 — 600 байт. При больших значениях у вас GC будет вызваться и отрабатывать настолько часто и долго, что добиться стабильных 30 FPS не удасться
Хватит врать с этой системой моя игра щас в топах стимах, спонсоры меня профинансировали, член стал больше на 5 см, бицуха на 10 см, бабы теперь не могут мимо меня пройти и вообще самое главное военкомат от меня отстал!!!

я смотрю у вас комментарии не сильно отличаются друг от друга-то.

А у тебя мозг отличается от нашего слишком низким IQ.
Вы правы для мобильных платформ возможно это будет и сложно. Но я их не не рассматриваю для себя. Что касается количества объектов. Так вот у меня был проект, один из моих первых, так сказать. На сцене работало порядка 2-х тысяч объектов, некоторые из низ с достаточно солидным набором компонентов. Все было связано, запутано. Так как почти все в методах Update обрабатывалось. И единственная сложность в этом проекте была, это его поддержка и основная задача сформировывалась это сделать архитектуру грамотнее и удобнее, чтобы упростить и ускорить процесс. Вопросов касаемо производительности вообще не возникало, так как ниже 70 кадров в секунду никогда не проседало. Я не планирую участвовать или создавать ААА проекты, я ориентируюсь на инди разработку и статья как раз для начинающих инди разработчиков. Если вдруг у меня бы встал вопрос о просадке производительности, то тогда это бы стало более приоритетным. Но до тех пор, удобство и скорость разработки, а также maintenance проекта находится в приоритете.
Если вдруг у меня бы встал вопрос о просадке производительности
то было бы уже поздно менять архитектуру.
Я не планирую участвовать или создавать ААА проекты
А вот ААА проект редкие просадки FPS из-за GC не так сильно убьют впечатление от игры, как на мобилках.
Ну справедливости ради первый кусок про клик мышки это 1 аллокация на клик мышки, событие настолько редкое по сравнению с остальными аллокациями, что можно пренебречь. В остальном да, жуткий перебор, даже без gc было бы излишне.
чем больше будет слушателей, тем дольше будет выполняться его обработка. Для того чтобы уйти от этого, нужно реализовать асинхронную обработку уведомлений

В корне не верно. Асинхронная обработка имеет свой оверхед и выполняться будет дольше.
Sign up to leave a comment.

Articles