|
|
« Предыдущая тема | Следующая тема » |
Опции темы | Опции просмотра |
|
|
|||||
[+1.3 07.12.11]
Регистрация: Feb 2011
Сообщений: 121
|
Помогите разобраться с классом-диспетчером
Прошу прощения что не в той ветке, но не знал в какую именно воткнуть.
Суть вот в чем... допустим, мы пишем игру... у нас есть основные стадии: 1) Инициализация(GAME_INIT) 2) Запуск игры(GAME_RUN) 3) Окончание игры(GAME_OVER) у Мука и тут на форуме мне сказали что надо использовать класс-диспетчер... Как я понял, этот класс будет генерировать события: 1) dispatchEvent(GAME_INIT); 2) dispatchEvent(GAME_RUN); 3) dispatchEvent(GAME_OVER); ..., а в основном классе мы будем отлавливать эти события и в зависимости от ситуации выполнять различные действия... Вопрос(ы) собственно вот какие: a) Класс-диспетчер ДОЛЖЕН знать когда какое событие генерировать,так? Т.е., пусть даже в самом начале он сгенерирует событие GAME_INIT, НО этот класс должен знать когда ему генерировать событие GAME_RUN. Получается, что наш основной класс должен в свою очередь после окончания инициализации сгенерировать событие INIT_OVER, которое должен отловить класс-диспетчер, я правильно мыслю? b) Если мои рассуждения по первому вопросу верны, тогда, чем плох вариант когда мы в основном классе вставим функцию Init(), а после ее окончания функцию Run() и т.д.? c) Вопрос: <Текущая стадия выполнения программы> <---> <Enter_FRAME>. С этого, собственно и начались все мои размышления... Нужны ли для каждой стадии свои ENTER_FRAME? Т.е.,... 1) стадия GAME_INIT, на экране заставка, прогресс_бар и т.д. 2) стадия GAME_RUN -> removeEventListener(Event.ENTER_FRAME, initEnterFrameListener); addEventListener(Event.ENTER_FRAME, runEnterFrameListener); removeEventListener(Event.ENTER_FRAME, runEnterFrameListener); addEventListener(Event.ENTER_FRAME, overEnterFrameListener); addEventListener(Event.ENTER_FRAME, update); function update():void { switch(gameStage) { case GAME_INIT: /*и в этом месте вызов update() всех отображаемых объектов типа прогресс бар и т.д. */ case GAME_RUN: /*и в этом месте вызов update() всей сцены */ /*и т.д.*/ } } Всем заранее спасибо за ответы З.Ы. А нельзя ли создать ветку, в которой бы обсуждались темы типа "Как правильно(корректно, лучше) делать то-то и то-то ", т.е... например, вы пишете движок с использованием DirectX...и там у вас... фронт-буфер, бэк-буферы...и куча еще чего... тут же всего этого нет... но есть свои нюансы, правила и т.д., т.е. как правильно писать проги с учетом флэш или как тут уже была тема ENTER_FRAME vs Timer.... |
|
|||||
Регистрация: Mar 2007
Сообщений: 545
|
|
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
"класс-диспетчер должен знать.." – зачем ему знать? Он должен посылать событие. Я правда не знаю, кому и зачем, но Вы-то, видимо, знаете. А значит, знаете, КТО знает, когда их посылать))) Не, ну правда, разговор глухого со слепым. Вы откуда-то выдрали какую-то концепцию, и говорите о ней так, как будто каждый флэшер только так и делает. Но это не так.
Как бы я поступил с Игрой? Прежде всего, разбил бы ее на экраны, или режимы. Почти все игры начинаются с Welcome Screen, некоего "рекламного" постера с создателями, спонсорами и тд. На нем же может быть внедрен прелоадер и, не обязательно, – какие-то Правила игры. Затем обычно - MainMenu Screen. C этого экрана может идти разводка в другие экраны – создание нового профиля, выбор из сохраненных профилей, загрузка сейвов, выбор уровня сложности и т.п., а может быть одна кнопка start game. Следующий экран собственно и есть "игра". В случае завершения показывается либо Поздравление и титры, либо ужасный геймовер и выход в меню. Ну и по ходу игры может осуществляться выход в малое меню(пауза) – "продолжить/закончить/Главное Меню". Это краткий конспект, и в нем событий на порядок больше, чем в предложенном Вами варианте. 1. Должны ли экраны меню и т.п. быть завязаны на какие-то ентерфреймы? Очевидно, нет. Они завязаны на действия пользователя, нажатия кнопок меню. 2. Должен ли прелоадер и заставка быть завязаны на ентерфреймы? Очевидно, нет. Они завязаны на события прогресса загрузки от Лоадера. 3. Должен ли экран геймовера быть .... нет. Он завязан на событие "герой повержен", происходящее в игре. Итак, все смены экранов инициируются – Лоадером, пользователем и логикой (контроллером) игры. Сама игра может использовать ентерфрейм для управления ритмом происходящего и обновлением экрана с объектами игры. Но к смене режимов это никакого отношения не имеет. З.Ы. Тут весь форум о том, "Как правильно(корректно, лучше) делать то-то и то-то ". Сформулируйте еще конкретней?
__________________
Reality.getBounds(this); |
|
|||||
.
|
Похоже, что "Класс-диспетчер" заменяется на множество объектов-диспетчеров, которые сворачиваются в GOF State Pattern. Ближайшее соответствие представления — флексовая <mx:State />, переключаемая контроллером, реализующим основную (aka бизнес) логику на основе событий от вышеупомянутых диспетчеров. Они являются контроллерами, реализующими логику конкретного состояния.
|
|
|||||
[+1.3 07.12.11]
Регистрация: Feb 2011
Сообщений: 121
|
Цитата:
На счет разных экранов типа там интро, хренинтро... это все понятно... но... чтобы отобразить очередной экран(не кадр)...наш scene_builder должен опять же знать что отображать, т.е. в результате каих-то действий польователя или информации об окончании загрузки данных и инициализации. или нового режима к примеру пользователь нажал кнопочку "About".. наш scene_builder строит новую сцену... и получается, что этот scene_builder должен обо всем этом знать.... какой режим, какая стадия игры, не пукнул ли пользователь... и тут, получается опять... дуб или молчало.... т.е. если у нас сейчас интро...построй нам сцену со сплэшем и прелоадером.... а если мэйн меню, тогда построй мэйн меню скрин... опять я в начале пути....т.е. if(preloader) тогда, сделай то-то и то-то или же.... генерация очередного события.... и уже от того какое событие....в приемнике мы делаем то - то и то-то Добавлено через 18 минут Цитата:
Последний раз редактировалось imena; 25.10.2011 в 21:59. |
|
|||||
.
|
Цитата:
По таймеру ли, по степени загрузки графики или по каким-либо еще причинам произойдет диспатч события "гейм-овер", определяет контроллер конкретного состояния. Последний раз редактировалось dimarik; 26.10.2011 в 00:25. |
|
|||||
[+1.3 07.12.11]
Регистрация: Feb 2011
Сообщений: 121
|
понятно... спасибо еще раз. ))
|
|
|||||
Нуб нубам
модератор форума
Регистрация: Jan 2006
Адрес: Бердск, НСО
Сообщений: 6,445
|
Грубо, отложив всякие MVC и прочие бандитские штуки, как бы для тренировки логики рассуждая.
Представим, что у нас есть некий Управляющий Эпохами, а по-русски – менеджер экранов. Его задача проста: он убирает из списка отображения текущий модуль(экран) и добавляет в него новый. При этом, конечно, гасит всякую жизнь в удаляемом и инициализирует ее в новоявленном. Первый экран ему известен априори - это экран-обложка с прелоадером. Этот экран он выводит сразу при инициализации приложения. И сразу подписывается на некое событие от этого экрана, которое говорило бы – "я свою миссию закончил, все что мог сделал, отпустите на пенсию плиииз". Менеджер экранов знает, что получив такое конкретное событие от прелоадера, надо удалить его нафиг и показать Главное Меню. Кто продиспатчит это событие? Экран прелоадера. Для этого у него есть EventDispatcher (наследованием или композицией), и есть событие от Лоадера Event.COMPLETE, которое и означает, что его миссия закончилась, данные загружены. Когда это событие поймано, логика ЭкранаПрелоадера (мини-контроллер, о которых говорит dimarik) решает – либо послать событие что экран пора убивать, либо показывает на этом же экране кнопку НАЧАТЬ, если задумано так, и подписывается на событие клика от нее, чтобы в обработчике клика опять же послать сообщение о завершении миссии. Так маленький модуль-экран сообщает большому боссу Менеджеру Экранов, что сложились условия для перехода на другой экран. Менеджер принимает решение - убивает экран прелоадера и добавляет "на сцену" экран Меню. У Меню могут быть состояния, не требующие смены экрана, обрабатываемые в самом экране Меню (другие окна меню – меню сейвов, окно настроек и тп). Но обязательно есть выход на другой экран – на саму игру. У Меню безусловно есть своя логика, свой контроллер, получающий события от всех кнопочек на экране и предпринимающий разные действия. Получив событие клика от кнопки "начать игру", он посылает событие Большому боссу - GAME_START_SELECTED. И босс, менеджер экранов, делает соответствующие действия: удаляет экран меню и добавляет экран Игры, подписываясь на разные события от этого экрана – требования выхода в Главное Меню, завершение игры победой и наоборот, пресловутый геймовер. Игра идет себе по своей логике, пока герой не победит или не погибнет. Трудно предположить, что логика Игры – контроллер Игры – не узнает, что это произошло, верно? А узнав, он незамедлительно сообщает об этом событием, которое ловит Большой босс и выставляет на сцену соответствующий экран.
__________________
Reality.getBounds(this); |
|
|||||
[+1.3 07.12.11]
Регистрация: Feb 2011
Сообщений: 121
|
спасибо за столь подробное разъяснение...
Скажу честно... я очень доволен. Спасибо еще раз. |
Часовой пояс GMT +4, время: 18:59. |
|
« Предыдущая тема | Следующая тема » |
Опции темы | |
Опции просмотра | |
|
|