Проектирование текстового квеста - Страница 2

Wolsh · 24.10.2017, 18:26

Нет.
Хотя поначалу тебе всегда будет хотеться сделать все задом наперед, аж на уровне подсознания.
Но "иерархия" подразумевает, что никакое _gameview.addChild(this); невозможно в принципе. Потому что это приказ родителям от ребенка. В иерархии приказывает тот, кто стоит выше. Он создает себе инструмент и управляет им. Если инструмент считает, что он знает больше, он посылает событие родителям "вас вызывают в школу". Но даже в этом случае родители сами решают, что всвязи с этим предпринять.
Нормальный код выглядит примерно так:

Код AS3:

//// MainView.as
_model.addEventListener(ModelEvent.STATE_CHANGE, handlerStateChange);
//... 
private function handlerStateChange(event:ModelEvent):void {
_stateView.show(_model.currentState);

То есть Вью получает событие от Модели "стейт изменился", забирает из модели новый стейт и отдает его СтейтВью.

Добавлено через 23 минуты
"И теперь уже прямо в StateView, не отходя от кассы, мы можем создавать объект TextField и, написав несложный метод, выводить в него тексты"

Добавлено через 36 минут

Цитата:

Я верно понимаю, что в мы передаём в экземпляр StateView ссылку на MainView, первым делом записываем её в приватную константу и "добавляемся" в неё

Давай вот сам подумай. Откуда взялся этот "экземпляр StateView"? Кто его создал? MainView? Так зачем городить огород, передавая ссылку в экземпляр, если тот кто его создал, тут же может его и добавить? У тебя вообще звучит так, словно и не MainView его создал, а кто-то где-то, и сказал куда добавиться. А ничо, что там наверно уже сотня таких добавлена, потому что про удаление таких предыдущих молодцов ты не говоришь. Это то, почему экземпляр не должен САМ себя куда-то добавлять и сам себя удалять (тут обычно холивар начинается любителями аутодафе) — тупо потому, что он не знает общей картины и даже цели своего существования, это знает только Создатель. Создатель знает, что если надо добавить новый экран, то старый надо удалить. И у него ЕСТЬ ссылка на этот старый, а у нового нет. Это только одна из миллиарда возможных ситуаций класса Конфуз.as ))
В моем примере _стейтВью один и всегда добавлен на сцену; но даже если бы это было не так, МейнВью ЗНАЛ бы, что перед созданием нового стейтВью надо удалить старый — они в его руках, он их создает и разрушает.

Добавлено через 43 минуты
Новый экземпляр нужно создавать тогда, когда необходимо сохранить старый.
Если старый не нужен, он очищается и строится заново.
"Используется повторно".

Appleman · 24.10.2017, 22:58

Цитата:

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

Нормальный код выглядит примерно так:

Код AS3:

//// MainView.as
_model.addEventListener(ModelEvent.STATE_CHANGE, handlerStateChange);
//... 
private function handlerStateChange(event:ModelEvent):void {
_stateView.show(_model.currentState);

То есть Вью получает событие от Модели "стейт изменился", забирает из модели новый стейт и отдает его СтейтВью.

Ы-ы-ы-ы... У меня башка лопается

Хорошо, а если у нас ситуация, когда стейт не меняется? Я уже спрашивал на счёт отправки содержимого в TextField. Все компоненты - на своих местах, без изменений. Но в TextField нужно поочерёдно вывести 4 куска текста, причём некоторые - со своим TextFormat-ом. Как это делается, если id текстов определяются в model? Как их "переправить" в МэйнВью вместе с форматами?

Цитата:

А ничо, что там наверно уже сотня таких добавлена, потому что про удаление таких предыдущих молодцов ты не говоришь.

Грешно смеяться... Я создать-то толком не могу, а ты - удалять!

Wolsh · 24.10.2017, 23:28

2) Ну, форматирование текста можно задавать с помощью html, какой-никакой а в AS3 он есть. То есть уже в xml можно хранить текст отформатированным. Либо, как вариант, утвердить несколько конкретных форматов и размечать текст своим способом (заключать в теги со "своими" застолбленными именами, типа <boldred/>), а потом парсить и назначать этим кускам нужный, заранее известный ТекстФормат.

1) Ну не меняется стейт и не меняется, другое событие значит пошлешь)

0) У всех лопается, это ж не банер "Осенние скидки купи сейчас по летним ценам". Спрашивай что непонятно, а то широкими то мазками я горазд размахивать, мне ж отсюда не видно, в чем у тебя затык.
Я вот уже не могу без MVC представить архитектуру, а ты ведь по-настоящему не углублялся в эту тему? К тому же, никто кроме тебя не знает, что за фантазии тебя обуревают. "Стейт не меняется а текст меняется". Так что, картинка на фоне не меняется чтоли? Ну, СтейтВью как-то должен с этим разобраться, для него не должно быть проблемы понять, что картинка та же) Но если все тоньше и это именно НЕ новый стейт, то все-равно это какое-то изменение в модели и она должна об этом сообщить заинтересованным лицам (Вью).
У тебя щас проблема наверное в том, что идей много а окончательной формы пока не видно. Задача твоя как проектировщика определить некие стандарты: что выводиться на экран будет то-то и то-то, таким вот образом раз, и вот таким образом два. Есть вот такой стиль, и вот такой, и нужен еще третий. Найти в куче идей какие-то общие моменты, чтобы разные интересные штуки можно было оформить каким-то общим способом, чтобы этих способов было не 100500 а 5-7. Это важно и для игрока, чтобы его не ошарашивал интерфейс, хаотически меняющийся на каждом слайде. Важно сформулировать, какие именно возможности тебе нужны от движка, иначе на любое решение ты будешь восклицать "а если мне захочется еще и вот так!", и тогда конца-края вообще не дождешься.

Appleman · 25.10.2017, 00:56

Цитата:

Спрашивай что непонятно, а то широкими то мазками я горазд размахивать, мне ж отсюда не видно, в чем у тебя затык.

Спасибо, но чтобы спрашивать, нужно сформулировать. Боюсь, вопросы в стиле "как мне сделать, чтобы стало всё красиво" не найдёт сочувствия и поддержки. А у меня пока действительно затык, когда я и дальше продвинуться не могу, и спросить не понимаю, чего конкретно

До сего момента я азартно писал всякие сервисные функции типа подбора текста и подстановки туда слов в нужных падежах. А как до самого геймплея дошёл, тут и алис!

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

Цитата:

Я вот уже не могу без MVC представить архитектуру, а ты ведь по-настоящему не углублялся в эту тему?

Значит, недостаточно углублялся, раз застрял. На самом деле пытался. Хотя бы на концептуальном уровне. Мысли пока следующие. Я всерьёз размышлял, нужна ли мне вообще MODEL для выбранной механики. По итогу решил, что всё-таки да, нужна. Ибо не важно, каким образом и как часто требуется обновлять визуальный ряд: по милисекундам для реал-тайм игры или раз в минуту по клику. Всё равно принцип тот же. А вот необходимость в CONTROL для меня кажется излишней, т.к. никакого прямого управления процессом со стороны игрока нет, только выбор предлагаемых вариантов на каждой стадии. Из этого я сделал вывод, что "С" мы можем интегрировать в "М". Таким образом, общая архитектура получилась примерно такой, какую советовал ещё коллега Nooob в самом начале недавно закрытой темы по проектированию: data + model + view. Это я и взял за основу. Правда, признаюсь честно, местами слабо чувствую разницу между data и model

Цитата:

К тому же, никто кроме тебя не знает, что за фантазии тебя обуревают.

Теперь про механику конкретнее. Я решил пока отодвинуть в сторону "большую" игру и попрактиковаться на отдельном её элементе, а именно на схватках. Они по задумке могут проходить в режиме автобоя, а можно запустить мини-игру. Её механика повторяет общеигровую, просто вариативность меньше. Вот такую мини-игру я сейчас и разрабатываю. На старте мы имеем нашего героя с полным набором RPG-шных свойств: постоянных характеристик, неизменных на протяжении игры, набором изменяемых параметров, навыков и т.п. На него "надеваются" предметы, дающие определённые свойства. Также имеем врага - NPC, обладающего примерно аналогичным набором свойств. Здесь есть одна из "фишек" геймплея - в зависимости от степени изученности данного врага, для игрока данные о нём выводятся с разной степенью детализации, это оказывает влияние на игровые решения. Собственно и всё. Локация - зафиксирована, пока это будет чисто поле, чтобы ещё больше не усложнять.

Итак, на старте рассчитываем начальные параметры обеих сторон, выводим игроку полную инфо о своём герое, а также инфо о противнике, но "отфильтрованную" через степень знания о нём. Рисуем картинку, всякие полоски здоровья и т.п.

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

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

Как-то так, если отбросить все усложнения, которые разумеется, также планируются: всякие бафы/дебафы, проверки на специфические свойства и т.п. Наверное, в текущей версии только возможность смены инвентаря нужно добавить.

ZergMaster · 25.10.2017, 12:29

рекомендую замечательную статью (MVC, часть 1: про дубовый стол и сиськи), которая должна ответить на некоторые вопросы.
И, да, не стесняйтесь зарисовывать архитектуру снова и снова.

Appleman · 25.10.2017, 14:18

Цитата:

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

рекомендую замечательную статью (MVC, часть 1: про дубовый стол и сиськи), которая должна ответить на некоторые вопросы.

А кстати, да, точно. Спасибо большое! Читал этот опус давно, когда совсем ничего ещё не соображал. Тогда подумал, что автору можно какую-нибудь премию за сам стиль изложения присудить.

Теперь можно с большим знанием дела ещё раз проштудировать.

P.S. и да, кто мой предыдущий пространный пост прочитал, просьба не воспринимать всерьёз мои опусы про ненадобность контроллера. Я его почему-то воспринимал, как реализацию управления со стороны игрока, а перечитав любезно порекомендованную статью об MVC, понял, что сморозил сущую глупость.

Добавлено через 2 часа 46 минут
Начал, пыхтя, продумывать архитектуру в стиле MVC... Возник первый содержательный вопрос.

Планируя Вью, нужно ли различать такие понятия как условно "разметка экрана" и "обновление данных из модели"? У нас есть ряд компонентов, которые, с одной стороны, непосредственно связаны с обновляющимися данными модели (тот же TextField для вывода основного текста), а с другой - сам объект (но не текст внутри) - находится на одном и том же месте от начала и до конца игры. Что с таким делать?

Добавлено через 2 часа 54 минуты
...и ещё вопрос. Я выше жаловался на плохое понимание разницы между "data" и "model". Прокомментируйте, плиз, мои мысли.

Сейчас у меня в пакете data есть класс Character, который содержит все свойства персонажа. Причём они, эти свойства, могут изменяться в процессе игры, что в свою очередь, находит отражение в отображаемом игроку содержании. Правильно я понимаю, что в таком случае, мой Character - уже по этому признаку никакой на фиг не data, а model в чистом виде? А если так, то и создавать его должен главный контроллер в начале работы с добавлением всяких событий на обновление и т.п. так? В этом случае становится вообще непонятно, нужен ли мне класс Character в том виде, в котором он у меня есть...

ZergMaster · 26.10.2017, 17:28

Я обычно стараюсь не усложнять и проектирую в основном так - сначала создаю сущностную диаграмму - это когда ты программу расписываешь на сущности, объекты и их взаимодействия. Ну. например, в твоем случае, это, насколько я понял, --
персонаж(я), вещи, враг, поле. 4 сущности. Они зарисовываются в виде кружочков. Далее обозначаем отношения - вещи носятся на персонаже и влияют на характеристики. Поле содержит в себе персонажа и врага. Персонаж сражается с врагом. Далее рядом с кружочками выписываем свойства - у персонажа это характеристики (ну там сила, скорость передвижения, вещи(массив)), у врага, видимо, тоже (скорее всего персонаж и враг это два экземпляра одного класса герой, или как минимум наследуются от одного класса, так как имеют много общих свойств). Выглядеть это должно примерно так

и на всякий случай ссылкой

не стоит сильно заморачиваться и усложнять - наоборот, схема должна быть простой и наглядной, чтобы впоследствии при одном взгляде на нее было примерно понятно. Если интеренсо, почитай про ER-диаграммы.

Далее уже рисуем UML на этой основе. Разделяем сущности на классы, разделяем каждую сущность на модель - описание состояния объекта, его свойства, вьювер - отображение состояния объекта и контроллер - изменение состояния объекта. Важно помнить, что изменяем мы именно состояние, а отображаем уже по факту изменения состояния. Так будет проще потом изменять и меньше вероятности потерять связь с ~~реальностью~~ проектом.

Подитожим. Разделяем программу на объекты, а каждый объект отдельно по модели MVC. Профит.
По крайней мере, примерно так делаю обычно я.

Appleman · 26.10.2017, 23:54

ZergMaster, спасибо. Общая концепция понятна. Я из того, что ты написал, одну вещь уточнить хотел бы. Если для каждого обособленного объекта делать свою полную триаду MVC, то нужно налаживать какую-то иерархию и взаимодействие между ними. И если с Вью более-менее понятно, то как обрабатывать взаимодействие контроллеров? Вообще, насколько это жёсткое требование? Мне пока придумалось иметь один главный контроллер, свои модели на каждый объект и вьюшки, связанные с ними...

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

ZergMaster · 27.10.2017, 00:04

Appleman добавил картинку в прошлый пост. Куда-то она делась.
Ну да, иерархия. Но всегда есть главный вьювер, главная модель и главный контроллер. У меня как правило они вложены друг в друга по принципу деревьев - в основном для читабельности.
Ты начни с того, чтобы сделать одну главную модель, одну главную вьюху этой модели и один контроллер. А дальше уже будешь добавлять по мере необходимости.

Добавлено через 10 минут
На самом деле, конечно, совсем не обязательно делать для каждого объекта свою триаду. Я бы сказал -
не надо. Можно для группы схожих объектов. Или вообще по одной на всю программу (что бывает тоже редко, так как получается слишком много кода в одном месте.. удобно его разложить по полочкам все-таки). А может модель MVC реализовываться вообще только для части программы - где это удобно. Но это все придет в будущем, а пока лучше делать по одной главной. Тут нет каких-то особых правил. Главное - изучить общую концепцию на собственном опыте и в будущем применять его для удобства своего и своих близких (что тоже важно, чтобы читающий за тобой программист не проклинал тебя слишком сильно)

Wolsh · 27.10.2017, 01:20

Цитата:

...и ещё вопрос. Я выше жаловался на плохое понимание разницы между "data" и "model".

В MVC нет такой категории "data". Данные бегают туда-сюда постоянно. Вью забирает и отображает данные из Модели, но она же выступает иногда поставщиком, как ни крути. Модель отличается от тупого хранилища данных тем, что выполняет так же и их обработку, для чего и обладает Логикой. В некоторых интерпретациях MVC, которые насочиняли бывшие РНР-шники, Модель является аналогом Базы Данных на сервере, а вся логика сосредоточена в Контроллере (аналог РНР-скрипта; соответственно клиент — браузер пользователя — это Вью). Для ActionScript такое деление внутри одного файла(!) бессмысленно. Модель хранит данные и она же с ними работает, это логично. Контроллеры обеспечивают поставку новых данных от Вью (если нужно, то и с сервера), включая управление (действия игрока).
В разных режимах приложения одни и те же действия пользователя должны интерпретироваться по-разному. Яркий пример — нажатия клавиш. Во время игры клавиши со стрелками вверх/вниз могут передвигать игрока по карте, а когда на экране Меню — обеспечивают переход между вариантами; в окне настроек могут менять громкость звука и т.п. Удобно пихать эту интерпретацию в контроллеры: имеется ввиду, что для каждого состояния программы существует свой контроллер, который просто не слушает то что не надо и вызывает правильные методы в Модели в ответ на то, что слушает. А поскольку "состояния" так или иначе завязаны на то, что показывает сейчас Вью — Меню, Инвентарь, Диалог, Настройки, Видеозаставка, Поединок — удобно все их делать отдельными Вью со своими контроллерами. А вот насчет множества Моделей это перебор. Ну, или они могут быть как части одной Модели: ты можешь считать что твой Character это CharacterModel, смысл от этого не очень поменяется, разве что возникнет вопрос "а как быть с CharacterController? Что он должен делать?" )) При разделениях Моделей на множество важно осознавать, насколько они зависимы друг от друга всмысле обмена данными. В режиме поединка тебе постоянно надо иметь данные о персонаже и оппоненте "вместе", да еще и об их аммуниции; а вот глобальное меню игры здесь вроде как совсем не при делах — оно может быть отдельной триадой, так как его данные абсолютно обособлены.