Аппетит событий и DI
 

Лет много назад прочитал и запомнил что-то вроде.
Вопрос не про спрайты и визуальные объекты, как правильно работать с ними довольно известно.

Вопрос в некотором смысле про mvc, когда создаются классы событий, и все связи работают через слушателей и команды. Особенно когда события передают данные, например каждые 50ms увесистую стопку json, существенно ли это отягощает cpu и ram??? в сравнении с прямой связью между классами.

В проекте используется robolegs - всё супер и клёво, но всё только начинается и пока на мобилке приложение без графики занимает 7метров, и летает, но функционал будет нарастать и если строго следовать правилам mvc, то количество слушателей в легкую перевалит за сотню, а мобилный проц всёж думаю ещё послабей четвёртого пня будет.

по сути, это дублирование вопроса заданного на недавно на потрошителе

и dependency injection, по идее не много где его использую, но всё же хочу успокоится, что нет у него тех проблем с понижением производительности что были с биндингом во флексе.

Какой смысл гонять каждые 50ms увесистую стопку json? Тем более json.

Добавлено через 4 минуты
Вы это читали?

DI не заменяет события
DI это механизм создания зависимостей а не разновидность обсервера

роботлегзовский инжектор, кстати тоже работает не мгновенно из-за вызовов describeType

события можно заменить на signals или на коллбэки

Экшен-игра перемещение игроков, выстрелы. Прощупываю минимальный отклик чтоб было играбельно как quake скажем. Не знаю, но подозреваю там как-то так же сделано. Json в bytearray спрячется по необходимости.
Читал не всё, но над некоторыми кусками медитировал часами, цитируемую строчку пропустил, она вроде значит
injector.mapSingleton(HexEngine); - так не рекомендуется
injector.mapSingletonOf(IPhysModel,SimplePhys) - а так оно самое?

artcraft, пасиб за ценную инфу,
инжект работает не мгновенно только только в момент инициализации, или при любом вызове/установки методы/параметра? - этож тогда плохо получается, быстрей работать с настоящей копией модуля.

А вообще вопрос о скорости выполнении сотен событий в секунду, в разных частях программы.
fps геймплей он такой и физику посчитай и графику нарисуй и с сервера прими и на сервер отправь.
Именно в инициализации самих событий как прокладки между... а не скорости выполнения привязанных к ним метод.

Если оно критично - в топку mvc, используем другой способ.

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

Насчет json. Я так и не понял где вы его применяете. Внутри приложения? Нет смысла. Для передачи данных между игроками и/или сервером? В случае шутера, слишком расточительно. Есть множество более дешевых бинарных форматов, типа AMF. В конце-концов можно свой протокол написать, точно отвечающий нуждам игры и не имеющий ничего лишнего.

Почтайте о синхронизации состояний в онлайн играх. Например, тут и тут.

Да, для обмена с сервером, да изменим по необходимости на свой бинарный формат, это не сложно.
Сложно будет изменить архитектуру приложения если окажется что mvc тут далеко не лучшее решение, и мне так кажется всё больше и больше. Тема была создана понять - кажется мне, или это реальность?
Спасибо за статьи, прочитал очень интересно, некоторые мысли автора там тоже догадки, остальное в точности подтвердило мою реализацию Dead Reckoning и 20Hz работы сервера, реализация SimTick интересна но не так отзывчива.

В лес уходим господа )) Вопрос был о производительности событий, и похоже, что они не очень подходят для игр вроде quake. Не говоря уже о mvc паттерне, с которым у меня возникли вопросы о разумном использовании ресурсов cpu и ram.

Вопросы синхронизации, интервала и способа передачи данных между клиентами, немного оффтоп этой темы. Тут о способах и скорости передачи данных между модулями, - этих данных много и часто, задержки в 15-35ms могут быть критичны.

Тормозит не mvc, тормозят события.

События достаточно производительны, если их не слать тысячами (например, летит пуля и сигнализирует "я лечу". это уже маразм).
Статьи я вам привел как раз что бы вы избегали этого "много и часто". Нет в этом необходимости.
Между какими модулями?
Что вы подразумеваете под mvc? Физические движки по-сути контроллеры. Iso объекты в изометрических играх — модели в чистом виде, у которых есть вьюхи (их отображение). MVC как концепция и паттерн отлично ложится на игры, универсальные архитектурные фреймворки нет (если говорить непосредственно о игровом процессе).

В своё время мы паковали обычные Object'ы с динамически созданными полями в AMF и на выходе получалось почти то же самое, что и JSON. В каких случаях это менее расточительно?

Где на выходе?
Менее расточительно по размеру передаваемых данных, менее расточительно при сериализации/десериализации.