Comments 12
Внутри создадим простой дженерик метод расширения, который будет оборачивать любой инстанс в массив
Господи, сколько же вас еще придет из кровавого enterprise-а в мой любимый, но все более и более тормозящий геймдев…
+5
Если хотите сделать что-то сложнее одного бегающего человечка, не нужно делать так. С таким количеством аллокаций производительность убита на корню.
+2
Какие именно аллокации, вернее под какие структуры, под которые бы проводились аллокации, по вашему мнению должы убить производительность?
0
аллокации в апдейт методах
Массивы
Также, то что уже сказали до меня: link
И это только для управления одним персонажем. А если в у нас будет в сцене 5-10-20 объектов построенных на этой системе?
Возможно для десктоп платформ это еще может работать в небольших инди проектах, то для мобильных проектов это недопустимо. На проектах которых мне довелось работать, количество аллокаций в кадр было в районе 500 — 600 байт. При больших значениях у вас GC будет вызваться и отрабатывать настолько часто и долго, что добиться стабильных 30 FPS не удасться
//Обрабатываем клик левой кнопки мыши
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 не удасться
+2
Хватит врать с этой системой моя игра щас в топах стимах, спонсоры меня профинансировали, член стал больше на 5 см, бицуха на 10 см, бабы теперь не могут мимо меня пройти и вообще самое главное военкомат от меня отстал!!!
-4
Вы правы для мобильных платформ возможно это будет и сложно. Но я их не не рассматриваю для себя. Что касается количества объектов. Так вот у меня был проект, один из моих первых, так сказать. На сцене работало порядка 2-х тысяч объектов, некоторые из низ с достаточно солидным набором компонентов. Все было связано, запутано. Так как почти все в методах Update обрабатывалось. И единственная сложность в этом проекте была, это его поддержка и основная задача сформировывалась это сделать архитектуру грамотнее и удобнее, чтобы упростить и ускорить процесс. Вопросов касаемо производительности вообще не возникало, так как ниже 70 кадров в секунду никогда не проседало. Я не планирую участвовать или создавать ААА проекты, я ориентируюсь на инди разработку и статья как раз для начинающих инди разработчиков. Если вдруг у меня бы встал вопрос о просадке производительности, то тогда это бы стало более приоритетным. Но до тех пор, удобство и скорость разработки, а также maintenance проекта находится в приоритете.
-3
Ну справедливости ради первый кусок про клик мышки это 1 аллокация на клик мышки, событие настолько редкое по сравнению с остальными аллокациями, что можно пренебречь. В остальном да, жуткий перебор, даже без gc было бы излишне.
0
чем больше будет слушателей, тем дольше будет выполняться его обработка. Для того чтобы уйти от этого, нужно реализовать асинхронную обработку уведомлений
В корне не верно. Асинхронная обработка имеет свой оверхед и выполняться будет дольше.
0
Sign up to leave a comment.
Управление персонажем с помощью SharedEvents