|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Проектирование текстового квеста
Друзья! Ещё раз спасибо за терпеливые объяснения. Делал по заветам мэтров, на сегодня имею:
1. кнопки - экземпляры класса MenuButton, которые умеют нажиматься и посылать по клику событие, содержащее свой номер (id:uint задаётся в конструкторе как входной аргумент); 2. меню - экземпляры класса Menu, которое строится с заданным кол-вом кнопок в колонку, создаёт и добавляет в себя сами кнопки и слушает события от них (даже успешно их принимает). Само пока правда ничего никому не посылает. 3. класс MainView, назначенный корневым DOC всего приложения (сей факт был отмечен банкетом), который пока что ничего особо не умеет, лишь помещает в себя это самое меню в порядке теста. Одно пока не получается: как заставить всё это работать на практике! Делал всё, ориентируясь на вот эти установки: Цитата:
Цитата:
У нас по ходу выполнения какого-то отвлечённого кода возникает момент, когда юзера надо спросить, да или нет. Получается, соблюдая цитированные выше принципы, мы должны "попросить" корневой DOC сделать и поместить в себя меню. Я ещё понимаю, что всё это "мясо" с инфой, необходимой для создания кнопок, можно "протащить" и через класс MainView... Понимаю, что корневой DOC может вызвать метод по созданию меню и помещению его в себя. Но как он поймёт, о чём именно мы спросили пользователя, и как практически обрабатывать события, получаемые от меню? Или это меню нужно "готовить" в одном месте, а через DOC - только выводить на экран? Поясните плиз или киньте ссылку с примером. И ещё одна тривиальная вещь у меня в голову не может уложиться. Какой смысл строить взаимодействие с визуальными компонентами посредством механизма событий? Понятно, что если мы говорим об обработке каких-то действий от пользователя, то без событий не обойтись. Но если, например, мы строим то же меню, то почему обязательно нужно слать ивент контейнеру? Почему нельзя в контейнере сделать публичным сам метод и вызвать его из любого места программы напрямую? |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Я даже не очень понял, о чем ты спрашиваешь((
Цитата:
PopupManager.confirm(Language.getText("127493"), deleteFileConfirmHandler); //... private function deleteFileConfirmHandler(result:Boolean):void {} То есть ты перепоручаешь все строительные работы профессионалам; твое дело задать вопрос и суметь получить ответ. На всякий случай намекну: надо еще спросить так, чтобы твоему герою никто голову не отрубил, пока игрок думает, действительно ли он хочет выбросить из инвентаря эти "поношенные обмотки", то есть надо/не надо остановить происходящее на экране на время диалога с пользователем. Цитата:
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
О-о-ох! Предлагаю спуститься на уровень ниже плинтуса, чтобы осознать мой вопрос. Я наверное зря привёл пример про "да и нет". Пусть будет обычное игровое меню со стандартными опциями: "Новая игра", "Загрузить", "Опции" и "Выход".
Я понял, как делать иерархическую систему для создания компонентов и вывода их на экран: MainView создаёт экземпляр класса Menu с некими входными параметрами и добавляет его в себя. Экземпляр Menu, используя эти параметры, создаёт и добавляет в себя экземпляры Button. Button-ы честно моргают при наведении и нажимаются при клике, даже посылают событие ButtonEvent, которое улавливается экземпляром Menu, о чём делается сообщение в консоль. А вот, блин, как связать всё это удовольствие с нужными действиями и "повесить" на нужные мне кнопки функции запуска, загрузки, выхода и т.п., вот до этого мне чего-то не допереть, уж простите. То есть меню корректно создаётся как объект на экране, но вот как использовать его "в боевом режиме" я не понимаю. |
|
|||||
Цитата:
var menu:Menu = new Menu(); menu.addEventListener(MenuEvent.Select, menuSelected) addChild(menu); function menuSelected(e:MenuEvent):void{ if(e.type == MenuEvent.RUN_GAME){// тогда грузим собственно игровой процесс} if(e.type == MenuEvent.OPTIONS){// грузим опции } if(e.type == MenuEvent.EXIT){//выход} } |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Партизан, спасибо, ясности стало больше. Но, по всей видимости, мой пример с главным меню всё-таки тоже неудачный, и не отражает специфики проблемы. Потому что оно всегда создаётся самим корневым DOC-ом и содержит фиксированное количество кнопок с известными заранее действиями.
Попробую ещё ближе к моему реальному проекту. Это - текстовый квест. Основная механика такова, что выбрав очередное действие, пользователь видит некий арт на бэкграунде, получает порцию текста в окно вывода текста, а также меню с вариантами дальнейших действий. Кликает на вариант и всё повторяется. Поэтому подобные меню появляются часто, но в первом случае там будет условно "пойти налево", "пойти прямо" и "пойти направо", а в следующую итерацию - "дать в лоб", "тихо обойти" и "попытаться охмурить" (причём последний вариант доступен только в случае, если герой - противоположного с NPC пола). Таким образом, каждый раз меняется количество опций, а также функции, которые будут выполняться при клике на тот или иной пункт. И аналогично, ни хрена я не понимаю, как тест выдавать. Пока сделал объект-область вывода, куда воткнул дочерний TextField, создал экземпляр в MainView. А как туда реальный текст посылать, да ещё с вариативным форматированием - опять туплю. Ведь текст создаётся в другом месте. Вернее сказать так: в процессе выполнения кода, обрабатывающего результат очередной итерации, появляется строковый id, по которому из XML с фразами на заданном языке вытаскивается нужный кусок текста. В консоль его прекрасно вывожу, а так отправить в окно вывода - не пойму. Такое ощущение, что упускаю какую-то очень простую и важную вещь во всём этом хозяйстве, без которой пазл не складывается и каменный цветок не выходит. Просьба пояснить, если я ещё неутомил своим ламерством Спасибо. |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Партизан — Запутаешь человека) Подписываешься на MenuEvent.Select, а потом спрашиваешь какого же оно типа))
Appleman — Ну вобщем, подписываешься либо на каждый тип события, либо передаешь в Событии строку, что же именно выбрал юзер. Можно не городить свой кастомный MenuEvent, взять DataEvent из коробки, у него есть свойство для транспортировки data типа String. Добавлено через 13 минут Ох же шь... Ну, тут тебе надо хорошенько продумать саму механику квестов, с таким то ветвлением.. То есть, на каждую стадию у тебя должен быть текст, описывающий ситуацию и к нему набор вариантов действий с какими-то ID (здесь может быть просто a, b, c), и к каждому варианту — адрес следующей стадии, то есть куда перейти в случае выбора этого варианта. Тогда получится запрограммировать механику абстрактно, то есть универсально для всех стадий, а не расписывать В КОДЕ каждый поворот сюжета))
__________________
Reality.getBounds(this); |
|
|||||
Нда, не хорошо получилось. Надо бы добавить пару подписок. или троеточие воткнуть в код
|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
Вот я кое-что из этой механики уже запрограммировал, но весь вывод пока только в консоль через trace. Теперь мучаюсь с выводом на экран в рабочем режиме (это даже для дальнейшей разработки и отладки нужно). |
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Как мне кажется, тебе нужен класс - наследник спрайта - представляющий собственно слайд (или как там это называется в скроллерах), кадр, шаг игры. Не данные, про которые ты говоришь — это в Модели, а именно визуалку. То есть то, что отображает твой CurrentState в виде фоновой картинки и "диалога". Скажем, StateView. Он, естественно, может включать в себя отдельные компоненты, то же "меню" (хотя мне в этом контексте название "меню" не нравится, сбивает, даже если технически оно правильное; я бы назвал "диалог" — и у тебя наверняка будут именно диалоги персонажа с неписями, и они будут точно также "оформлены"). Вот его тебе и надо учить показывать кликабельные варианты. Не надо пихать всю ответственность в мейнВью.
Что конкретно то не получается с выводом текста? Текстфилд, конечно, штука капризная и нужен некоторый опыт чтобы его настраивать как хочется.. но не настолько же, чтобы вообще текст вывести не получалось?
__________________
Reality.getBounds(this); |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Цитата:
Цитата:
Цитата:
Можно мне в режиме дурака для примера кусочек кода, показывающего взаимодействие корневого DOC и условного StateView? Я верно понимаю, что в мы передаём в экземпляр StateView ссылку на MainView, первым делом записываем её в приватную константу и "добавляемся" в неё: И теперь уже прямо в StateView, не отходя от кассы, мы можем создавать объект TextField и, написав несложный метод, выводить в него тексты? |
Часовой пояс GMT +4, время: 18:20. |
|
« Предыдущая тема | Следующая тема » |
|
|