[Appleman]

Сообщение от Wolsh

Эта страсть неистребима, засорять стейдж разными выкидышами. Вот вроде ничего не мешает иметь специальный слой поверх всего прямо в главном Вью, никаких проблем СРАЗУ разделить все отображение по слоям, чтобы HUD был всегда поверх мира, слой для главных Меню — поверх HUDа, а подсказки поверх всего (кроме, может быть, слоя с экраном для видеозаставок). Но нет, проще выплюнуть что-нибудь на стейдж.

Спокойно! Никто никуда ничего пока не выкидывает. Я потому и спрашиваю, что почуял, шняга какая-то выходит. Поясни, плиз, как размечать слои в главном вью? И как дочерние вью получат доступ к этим слоям?

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

Почему сразу пересматривать? Мне кажется, что это хорошая привычка - добавлять тултипы ко всем графическим элементам интерфейса для удобства игрока. В конце концов, там где одному видится сердце, другой увидит жопу. Дело такое.

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

Если в хинте (тултипе, сорри) раскрывается дополнительная информация (не ЧТО, а ПОЧЕМУ например), то другое дело.. Но тогда надо сначала продумать механику — будет ли элемент сообщать Менеджеру подсказок только текст подсказки, или будет передавать готовый ДисплейОбжект с картинками, шкалами и графиками, который соберет сам.

А что меняется, если раскрывается? Разве статический класс не может реализовать дополнительную логику, связанную с ПОЧЕМУ? Например, текст тултипа иконки зависит от значения какого-то свойства. Почему нельзя передать это значение (или экземпляр класса, содержащий это значение) прямо в статический метод, и всё сделать в нём?

А в остальном обычно делают так: элемент, который хочет рассказа о себе, регистрируется у Менеджера через статик метод register(), в который передает ссылку на себя и текст/готовый хинт, и может быть политику по размещению хинта (типа "сверху по центру, не двигать за мышкой"). Менеджер оформляет подписку на маусОвер/маусМув/маусАут для этого объекта и сохраняет текст/ДО и политику например в Dictionary. Когда с объектом случится запланированный наезд мышой, Менеджер закидывает его хинт в специальный высоколежащий слой для подсказок, а когда надо — вынимает его оттуда.

Менеджер также должен предоставить метод unregister(), который объект вызовет перед смертью в своем методе destroy().

Я правильно уловил, что главная суть и предназначение этой регистрации - это добавление слушателя событий экранного объекта? Скажи, пожалуйста, если использовать Dictionary, то что уместно использовать в нём в качестве ключей? Сами экранные объекты: иконки, кнопки, шкалы и т.п.? А если они также "собираются на лету" в рантайме?