Цитата:
а почему кстати используешь кастомный класс для контейнеров тутора?
|
Это не класс, а интерфейс. Поэтому он и называется ITutor. Дело в том, что это могут быть и не дисплей объекты, но методы set tutorID и get tutorID у них быть обязаны. Эти свойства им адаются сразу в конструкторе. Этот метод ищет ITutor'ы в дисплей листе. Некоторые могут присылаться с данными в команде от модели. Все должно работать так же
Цитата:
И не лучше ли хранить весь путь от стейжа, например stage.win1.panel2.btn1
|
Конечно нет. У меня Tutorial вообще не сзязан с игрой. Я могу его запросто перетащить в другую игру и только инструкции внутри переписать под нее. А если я сделаю так, то появится ненужная связанность. Да еще и не надежно прописывать такие "хардкодные" пути
Я делал много разных туторов для разных игр, и наконец пришел к решению, которое дает игроку одновременно и определенную свободу действий (все кнопки которые прямо не запрещены (кстати для запрета, достаточно внести ее tutorID в массив "шага" туториала), будут нажиматься и он сможет походить туда-сюда, что-то попутно поделать, например обыскать ящики), и в то же время не дает ему сильно отойти в сторону от заданий тутора. Никаких черных экранов с дыркой, в которой кнопка. Тут много опиций. Тутор можно легко превратить в полноценный игровой процесс с подсказками. Для этого и нужно, чтобы был общий интерфейс для разных типов объектов
Цитата:
да и поиск будет быстрее. надо только дать имена контейнерам
|
Этот поиск укладывается в тысячные доли секунды. Объектов на сцене всего пара сотен. Явно не самое слабое место в игре. Игрок даже не заметит никаких задержек, так что о скорости поиска я вообще не парюсь