Эта страсть неистребима, засорять стейдж разными выкидышами. Вот вроде ничего не мешает иметь специальный слой поверх всего прямо в главном Вью, никаких проблем СРАЗУ разделить все отображение по слоям, чтобы HUD был всегда поверх мира, слой для главных Меню — поверх HUDа, а подсказки поверх всего (кроме, может быть, слоя с экраном для видеозаставок). Но нет, проще выплюнуть что-нибудь на стейдж.
Статический класс для подсказок хорош тем, что предоставляет один ларек для обращений, или точку входа, или как там. Правда, всем непонятным элементам придется его импортить, чтоб зарегистрироваться, но если их не катастрофически много, то почему бы и нет (а если много, то явно интерфейс требует пересмотра — игрок не должен сидеть и в задумчивости наводить мыша на каждый объект на экране, вытаясь понять что это с помощью подсказок). Если в хинте (тултипе, сорри) раскрывается дополнительная информация (не ЧТО, а ПОЧЕМУ например), то другое дело.. Но тогда надо сначала продумать механику — будет ли элемент сообщать Менеджеру подсказок только текст подсказки, или будет передавать готовый ДисплейОбжект с картинками, шкалами и графиками, который соберет сам.
А в остальном обычно делают так: элемент, который хочет рассказа о себе, регистрируется у Менеджера через статик метод register(), в который передает ссылку на себя и текст/готовый хинт, и может быть политику по размещению хинта (типа "сверху по центру, не двигать за мышкой"). Менеджер оформляет подписку на маусОвер/маусМув/маусАут для этого объекта и сохраняет текст/ДО и политику например в Dictionary. Когда с объектом случится запланированный наезд мышой, Менеджер закидывает его хинт в специальный высоколежащий слой для подсказок, а когда надо — вынимает его оттуда.
Менеджер также должен предоставить метод unregister(), который объект вызовет перед смертью в своем методе destroy().
|
