Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Flash > ActionScript 3.0

Версия для печати  Отправить по электронной почте    « Предыдущая тема | Следующая тема »  
Опции темы Опции просмотра
 
Создать новую тему Ответ
Старый 22.10.2017, 16:19
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 1  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
По умолчанию Проектирование текстового квеста

Друзья! Ещё раз спасибо за терпеливые объяснения. Делал по заветам мэтров, на сегодня имею:
1. кнопки - экземпляры класса MenuButton, которые умеют нажиматься и посылать по клику событие, содержащее свой номер (id:uint задаётся в конструкторе как входной аргумент);
2. меню - экземпляры класса Menu, которое строится с заданным кол-вом кнопок в колонку, создаёт и добавляет в себя сами кнопки и слушает события от них (даже успешно их принимает). Само пока правда ничего никому не посылает.
3. класс MainView, назначенный корневым DOC всего приложения (сей факт был отмечен банкетом), который пока что ничего особо не умеет, лишь помещает в себя это самое меню в порядке теста.

Одно пока не получается: как заставить всё это работать на практике!

Делал всё, ориентируясь на вот эти установки:
Цитата:
Сообщение от undefined Посмотреть сообщение
бардак - это когда на кто-угодно добавляет дисплей обжекты на сцену.Правильно:есть один DO-контейнер, который создает дочерние DO-компоненты, каждый компонент рисует свои внутренности.Если надо выввести что-то специфичное(хинт или диалог поверх всего что есть на экране) - шлем контейнеру ивент с описанием что хотим.
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Когда кнопку нажмут, Меню(!) должно послать событие что юзер сделал выбор. На события наведение и увода мыши, нажатия и отпускания Кнопки должны уметь реагировать самостоятельно — это их ответственность. И, наконец, тот кто создал экземпляр Меню, подписывается на событие от Меню "юзер сделал выбор", и получив это событие, разбирается что делать дальше. Надо четко понимать где чья ответственность. Каждый элемент ниже по иерархии является самостоятельным в выполнении своей задачи ИНСТРУМЕНТОМ для того, кто выше: Кнопка должна уметь "нажиматься", Меню должно уметь предоставить выбор, тот кто создал меню — знать что делать с выбором. Это называется иерархия. Тот, кто ниже, обычно извещает того кто выше — своего создателя — о происходящих в нем изменениях, но РЕШЕНИЯ принимает только в своей области ответственности. То есть внутри Кнопки не содержится кода, запускающего игру. И в Меню его не содержится. Меню не запускает игру, это не его ответственность.
Итак, с кнопки - спрос маленький: появляется, нажимается, докладывает наверх "меня нажали", окей. Меню "знает" сколько надо кнопок, какой на каждой должен быть идентификатор лэйбла, активной или нет будет кнопка. Таким образом, через класс Menu нужно "протащить" как минимум по 3 аргумента для каждой из кнопок. По нажатии на кнопку оно докладывает наверх "нажата кнопка id такой-то". А вот что дальше (выше), я сообразить не могу.

У нас по ходу выполнения какого-то отвлечённого кода возникает момент, когда юзера надо спросить, да или нет. Получается, соблюдая цитированные выше принципы, мы должны "попросить" корневой DOC сделать и поместить в себя меню. Я ещё понимаю, что всё это "мясо" с инфой, необходимой для создания кнопок, можно "протащить" и через класс MainView... Понимаю, что корневой DOC может вызвать метод по созданию меню и помещению его в себя. Но как он поймёт, о чём именно мы спросили пользователя, и как практически обрабатывать события, получаемые от меню? Или это меню нужно "готовить" в одном месте, а через DOC -
только выводить на экран? Поясните плиз или киньте ссылку с примером.

И ещё одна тривиальная вещь у меня в голову не может уложиться. Какой смысл строить взаимодействие с визуальными компонентами посредством механизма событий? Понятно, что если мы говорим об обработке каких-то действий от пользователя, то без событий не обойтись. Но если, например, мы строим то же меню, то почему обязательно нужно слать ивент контейнеру? Почему нельзя в контейнере сделать публичным сам метод и вызвать его из любого места программы напрямую?

Старый 23.10.2017, 20:21
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 2  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Я даже не очень понял, о чем ты спрашиваешь((
Цитата:
возникает момент, когда юзера надо спросить, да или нет.
Это называется ConfirmWindow, то есть всплывающее (popup) окошко с текстом вопроса и двумя кнопками "да" и "нет". Можно и без событий:
Код AS3:
PopupManager.confirm(Language.getText("127493"), deleteFileConfirmHandler);
//...
private function deleteFileConfirmHandler(result:Boolean):void {}
PopupManager создаст стандартное окно класса ConfirmWindow с предоставленным текстом, разместит его в выделенном для попапов "слое"-спрайте в мэйн вью и либо подпишется на событие от него, либо передаст ему колбек-ссылку на функцию deleteFileConfirmHandler, это уж кому какая архитектура нравится.
То есть ты перепоручаешь все строительные работы профессионалам; твое дело задать вопрос и суметь получить ответ. На всякий случай намекну: надо еще спросить так, чтобы твоему герою никто голову не отрубил, пока игрок думает, действительно ли он хочет выбросить из инвентаря эти "поношенные обмотки", то есть надо/не надо остановить происходящее на экране на время диалога с пользователем.

Цитата:
Почему нельзя в контейнере сделать публичным сам метод и вызвать его из любого места программы напрямую?
Ну, ты и делаешь метод (слушатель, обработчик), только он не публичный и вызвать его может только тот, кому разрешили (добавив этот слушатель). Почему нельзя кому угодно в любой момент? Ну, потому что кто угодно — ничерта не знает, что происходит наверху. Это основы иерархии.
__________________
Reality.getBounds(this);

Старый 23.10.2017, 22:09
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 3  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Я даже не очень понял, о чем ты спрашиваешь((
О-о-ох! Предлагаю спуститься на уровень ниже плинтуса, чтобы осознать мой вопрос. Я наверное зря привёл пример про "да и нет". Пусть будет обычное игровое меню со стандартными опциями: "Новая игра", "Загрузить", "Опции" и "Выход".

Я понял, как делать иерархическую систему для создания компонентов и вывода их на экран: MainView создаёт экземпляр класса Menu с некими входными параметрами и добавляет его в себя. Экземпляр Menu, используя эти параметры, создаёт и добавляет в себя экземпляры Button. Button-ы честно моргают при наведении и нажимаются при клике, даже посылают событие ButtonEvent, которое улавливается экземпляром Menu, о чём делается сообщение в консоль.

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

Старый 23.10.2017, 23:06
Партизан вне форума Посмотреть профиль Отправить личное сообщение для Партизан Найти все сообщения от Партизан
  № 4  
Ответить с цитированием
Партизан
 
Аватар для Партизан

блогер
Регистрация: Nov 2007
Адрес: Almaty, Moscow
Сообщений: 396
Записей в блоге: 5
Отправить сообщение для Партизан с помощью Skype™
Цитата:
Сообщение от Appleman Посмотреть сообщение
А вот, блин, как связать всё это удовольствие с нужными действиями и "повесить" на нужные мне кнопки функции запуска, загрузки, выхода и т.п., вот до этого мне чего-то не допереть, уж простите. То есть меню корректно создаётся как объект на экране, но вот как использовать его "в боевом режиме" я не понимаю.
MainView запуская допустим Menu "спрашивает" что делать дальше:
Код AS3:
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){//выход}
}
грубо, но примерно так. Запуск игры(Run_game) и опции(options) делают примерно то же что и Menu, просто возвращают данные(которые запрашивает MainView) в контроллер(MainView) a Exit просто завершает программу.

Старый 24.10.2017, 00:28
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 5  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Партизан, спасибо, ясности стало больше. Но, по всей видимости, мой пример с главным меню всё-таки тоже неудачный, и не отражает специфики проблемы. Потому что оно всегда создаётся самим корневым DOC-ом и содержит фиксированное количество кнопок с известными заранее действиями.

Попробую ещё ближе к моему реальному проекту. Это - текстовый квест. Основная механика такова, что выбрав очередное действие, пользователь видит некий арт на бэкграунде, получает порцию текста в окно вывода текста, а также меню с вариантами дальнейших действий. Кликает на вариант и всё повторяется. Поэтому подобные меню появляются часто, но в первом случае там будет условно "пойти налево", "пойти прямо" и "пойти направо", а в следующую итерацию - "дать в лоб", "тихо обойти" и "попытаться охмурить" (причём последний вариант доступен только в случае, если герой - противоположного с NPC пола). Таким образом, каждый раз меняется количество опций, а также функции, которые будут выполняться при клике на тот или иной пункт.

И аналогично, ни хрена я не понимаю, как тест выдавать. Пока сделал объект-область вывода, куда воткнул дочерний TextField, создал экземпляр в MainView. А как туда реальный текст посылать, да ещё с вариативным форматированием - опять туплю. Ведь текст создаётся в другом месте. Вернее сказать так: в процессе выполнения кода, обрабатывающего результат очередной итерации, появляется строковый id, по которому из XML с фразами на заданном языке вытаскивается нужный кусок текста. В консоль его прекрасно вывожу, а так отправить в окно вывода - не пойму.

Такое ощущение, что упускаю какую-то очень простую и важную вещь во всём этом хозяйстве, без которой пазл не складывается и каменный цветок не выходит. Просьба пояснить, если я ещё неутомил своим ламерством Спасибо.

Старый 24.10.2017, 00:42
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 6  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Партизан — Запутаешь человека) Подписываешься на MenuEvent.Select, а потом спрашиваешь какого же оно типа))

Appleman — Ну вобщем, подписываешься либо на каждый тип события, либо передаешь в Событии строку, что же именно выбрал юзер. Можно не городить свой кастомный MenuEvent, взять DataEvent из коробки, у него есть свойство для транспортировки data типа String.

Добавлено через 13 минут
Ох же шь... Ну, тут тебе надо хорошенько продумать саму механику квестов, с таким то ветвлением..
То есть, на каждую стадию у тебя должен быть текст, описывающий ситуацию и к нему набор вариантов действий с какими-то ID (здесь может быть просто a, b, c), и к каждому варианту — адрес следующей стадии, то есть куда перейти в случае выбора этого варианта.
Тогда получится запрограммировать механику абстрактно, то есть универсально для всех стадий, а не расписывать В КОДЕ каждый поворот сюжета))
__________________
Reality.getBounds(this);

Старый 24.10.2017, 01:08
Партизан вне форума Посмотреть профиль Отправить личное сообщение для Партизан Найти все сообщения от Партизан
  № 7  
Ответить с цитированием
Партизан
 
Аватар для Партизан

блогер
Регистрация: Nov 2007
Адрес: Almaty, Moscow
Сообщений: 396
Записей в блоге: 5
Отправить сообщение для Партизан с помощью Skype™
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Партизан — Запутаешь человека) Подписываешься на MenuEvent.Select, а потом спрашиваешь какого же оно типа))
Нда, не хорошо получилось. Надо бы добавить пару подписок. или троеточие воткнуть в код

Старый 24.10.2017, 11:31
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 8  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
То есть, на каждую стадию у тебя должен быть текст, описывающий ситуацию и к нему набор вариантов действий с какими-то ID (здесь может быть просто a, b, c), и к каждому варианту — адрес следующей стадии, то есть куда перейти в случае выбора этого варианта.
Тогда получится запрограммировать механику абстрактно, то есть универсально для всех стадий, а не расписывать В КОДЕ каждый поворот сюжета))
Да, именно. Это наверное обратно в тему с вопросами по проектированию , но я кратно обрисую, что придумал. Планирую сделать класс CurrentState, хранящий инфо о текущей фазе игры: локация, участвующие персонажи и т.п. На основании свойств экземпляра Current State выводится нужный исходный арт и текст. Далее запускается метод отбора вариантов действий для игрока. Действие - это либо экземпляры класса, либо данные статической таблицы (помятуя о твоих советах в соседней ветке), но в любом случае они должны быть описаны некоторым набором свойств, корреспондирующих аналогичным свойствам других игровых объектов. Все они помещаются в массив, который перебирается поэлементно. Значения свойств каждого потенциального действия сравниваются с соответствующими значениями из currentState или экземпляров других классов, которые содержит CurrentState. Если все соответствуют, значит, действие может быть выполнено, и оно должно попасть в меню выбора для игрока. Таким образом, по итогу из общего перечня остаётся несколько доступных действий (вот их и надо как-то отправить в меню, и главное, получить обратную связь). Когда получена инфо, какое действие выбрал игрок, запускаем метод-обработчик, который получает на входе тот самый экземпляр (если действие - это класс) или идентификатор выбранного пользователем действия, и дальше уже "распихивает" задачи по специализированным классам: рассчитать результаты, обновить арт и текст, обновить значения свойств персонажей по результату, обновить CurrentState. Собственно, потом всё повторяется. Как-то так вчерне.

Вот я кое-что из этой механики уже запрограммировал, но весь вывод пока только в консоль через trace. Теперь мучаюсь с выводом на экран в рабочем режиме (это даже для дальнейшей разработки и отладки нужно).

Старый 24.10.2017, 14:32
Wolsh вне форума Посмотреть профиль Отправить личное сообщение для Wolsh Найти все сообщения от Wolsh
  № 9  
Ответить с цитированием
Wolsh
Нуб нубам
 
Аватар для Wolsh

модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
Как мне кажется, тебе нужен класс - наследник спрайта - представляющий собственно слайд (или как там это называется в скроллерах), кадр, шаг игры. Не данные, про которые ты говоришь — это в Модели, а именно визуалку. То есть то, что отображает твой CurrentState в виде фоновой картинки и "диалога". Скажем, StateView. Он, естественно, может включать в себя отдельные компоненты, то же "меню" (хотя мне в этом контексте название "меню" не нравится, сбивает, даже если технически оно правильное; я бы назвал "диалог" — и у тебя наверняка будут именно диалоги персонажа с неписями, и они будут точно также "оформлены"). Вот его тебе и надо учить показывать кликабельные варианты. Не надо пихать всю ответственность в мейнВью.
Что конкретно то не получается с выводом текста? Текстфилд, конечно, штука капризная и нужен некоторый опыт чтобы его настраивать как хочется.. но не настолько же, чтобы вообще текст вывести не получалось?
__________________
Reality.getBounds(this);

Старый 24.10.2017, 15:36
Appleman вне форума Посмотреть профиль Отправить личное сообщение для Appleman Найти все сообщения от Appleman
  № 10  
Ответить с цитированием
Appleman
 
Аватар для Appleman

Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
Цитата:
Сообщение от Wolsh Посмотреть сообщение
Как мне кажется, тебе нужен класс - наследник спрайта - представляющий собственно слайд (или как там это называется в скроллерах), кадр, шаг игры. Не данные, про которые ты говоришь — это в Модели, а именно визуалку. То есть то, что отображает твой CurrentState в виде фоновой картинки и "диалога". Скажем, StateView.
Да, я это и подразумевал, когда писал про класс CurrentState, что он создаёт наполнение для вывода на экран, а вот отделить непосредственно вывод в класс типа StateView не додумался. Согласен, как раз получается тандем "модель-вью".

Цитата:
Он, естественно, может включать в себя отдельные компоненты, то же "меню" (хотя мне в этом контексте название "меню" не нравится, сбивает, даже если технически оно правильное; я бы назвал "диалог" — и у тебя наверняка будут именно диалоги персонажа с неписями, и они будут точно также "оформлены"). Вот его тебе и надо учить показывать кликабельные варианты. Не надо пихать всю ответственность в мейнВью.
Окей, определились с термином "диалог".

Цитата:
Что конкретно то не получается с выводом текста? Текстфилд, конечно, штука капризная и нужен некоторый опыт чтобы его настраивать как хочется.. но не настолько же, чтобы вообще текст вывести не получалось?
Я похоже начинаю понимать, чего я упустил и из-за чего у меня ни хрена не получается. Я возможно слишком буквально и в лоб воспринял рекомендацию о том, что весь вывод на экран и взаимодействие с пользователем должны быть делегированы корневому DOC. С тем же текстом я рассуждал так. Получили идентификатор текста фразы, вытащили из XML на нужном языке. Теперь нужно создать какое-то событие, которое заставит MainView добавить этот текст в соответствующее поле. На этом - полный ступор.

Можно мне в режиме дурака для примера кусочек кода, показывающего взаимодействие корневого DOC и условного StateView? Я верно понимаю, что в мы передаём в экземпляр StateView ссылку на MainView, первым делом записываем её в приватную константу и "добавляемся" в неё:
Код AS3:
private const _gameview:MainView = mainView;
_gameview.addChild(this);
И теперь уже прямо в StateView, не отходя от кассы, мы можем создавать объект TextField и, написав несложный метод, выводить в него тексты?

Создать новую тему Ответ Часовой пояс GMT +4, время: 14:44.
Быстрый переход
  « Предыдущая тема | Следующая тема »  
Опции темы
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.


 


Часовой пояс GMT +4, время: 14:44.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.