Проектирование текстового квеста

[ZergMaster]

Спрашивается, на фига тащить всё через контроллер, если можно сразу из вьюхи принять в модель?

для порядку!! =)
На самом деле, конечно, можно и напрямую. Да порядка не будет тогда. По сути, это как и с названиями функций и переменных - не обязательно их называть как-то понятно, можно просто "а", "b", "c". Не обязательно соблюдать конвенцию формата кода, не обязательно избегать комментариев, делая сам код читабельным без них. Не обязательно вообще писать в классах - зачем, когда можно писать в нужном кадре нужного символа?))
Все это не обязательно и, в принципе, для того, чтобы написать пару скриптов или пару кнопок - это не нужно.
Но как только проект разрастается, ты бы хотел знать, что моделью у тебя управляет только контроллер и никак иначе. Как только проект становится большим, тебя успокаивает уверенность в том, что вьюха ничего не знает о контроллере и слушает только модель. Ты знаешь, что у тебя не остается рудиментарных вызовов не пойми откуда не пойми чего. Ты уверен, что никакая нечисть не забредет а мир твоего кода. Хотя нет, конечно, неизбежно забредет, но тебе будет гораздо проще её найти, если будет порядок. Ты будешь четко в курсе кто чем управляет и кто что использует. Это удобно. Только лишь для этого, как мне кажется.
Ну и, конечно, полиморфизма ради.=)

[Wolsh]

У Модели нет ссылки на Вью.

Не, я понимаю что у тебя при таком ответе первая мысль будет "ну так давай дадим ей ссылку".
Тут вопрос то в том, MVC или не MVC. Так же как заявление Godwarlock выше. Если ты не понял, зачем ТАК сделано в MVC, то ты просто еще не понял MVC, тут нечего стыдиться)))
Вообще, "Правильно" всегда включает в себя "Чтобы работало", но "Чтобы работало" вовсе не всегда "Правильно". MVC всегда кажется избыточно сложным, кажется что его правила придуманы так, чтобы все усложнить на ровном месте. И ключевое слово здесь — "на ровном месте". Знаешь пословицу — "гладко было на бумаге, да забыли про овраги"? Реальность такова, что место нифига не ровное. Последнее, о чем думает молодой программист, это ошибки, а тем более СИТУАЦИИ, в которых что-то может пойти не так. А еще есть такая мерзкая тема, как защита от взлома. Я вобщем хотел сказать, что пока для тебя ВСЁ приложение умещается в задачу "послать событие вот тут", место кажется ровным и понятным. И начинать с этого вполне нормально, если что. Если MVC непонятно, забей на него до поры до времени. Если амбиции не позволяют, штурмуй дальше. Сразу скажу: вся красота и опрятность MVC проявляется, когда написано полсотни классов хотя бы по 300 строк кода и архитектура типа "всё в кучу" уже тупо не помещается в голове.
У Модели нет ссылки на Вью, потому что Вью может заменяться в любой момент.
У Модели нет ссылки на Контроллер, потому что Контроллеры могут заменяться в любой момент.
Чтобы об этом помнить, надо как минимум представлять себе СИТУАЦИИ, когда Вью и Контроллеры должны заменяться. Если в твоей голове по отношению к этому приложению нет идей таких ситуаций, у тебя не будут возникать подобные мысли, верно? И тогда сама идея MVC становится какой-то муторной и бессмысленной. Это только первое положение MVC само собой моментально укладывается в голову — что есть Модель которая все расчитывает и есть Вью которая всё отображает. Потому что это естественное положение вещей. Но дальше в MVC еще много чего, что так вот сходу на голову не налазит. Это нормально.

[Appleman]

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

Чтобы об этом помнить, надо как минимум представлять себе СИТУАЦИИ, когда Вью и Контроллеры должны заменяться. Если в твоей голове по отношению к этому приложению нет идей таких ситуаций, у тебя не будут возникать подобные мысли, верно? И тогда сама идея MVC становится какой-то муторной и бессмысленной. Это только первое положение MVC само собой моментально укладывается в голову — что есть Модель которая все расчитывает и есть Вью которая всё отображает. Потому что это естественное положение вещей. Но дальше в MVC еще много чего, что так вот сходу на голову не налазит. Это нормально.

Я как обычно с конца отвечать начну Мне идея MVC не кажется муторной и бессмысленной. Сама по себе специализация компонентов M, V и C и их относительная независимость друг от друга - уже прекрасный подход, облегчающий планирование программы. Плюс сразу легко рисуются ситуации, когда одна модель "обслуживает" несколько вью. Тут тоже преимущества налицо! Так что отказываться от неё я точно не собираюсь. Просто пока у меня контроллер почти без дела простаивает, вот и подумалась такая крамола.

У Модели нет ссылки на Вью, потому что Вью может заменяться в любой момент.
У Модели нет ссылки на Контроллер, потому что Контроллеры могут заменяться в любой момент.

Проверил, действительно нет. У Контроллера есть ссылки на Вью и Модель, плюс есть ссылка у Вью на Модель, это правильно? И в связи с этим ещё один очень важный вопрос. С т.з. MVC подхода, нормально ли это, когда например, Контроллер напрямую "дёргает" модель, вызывая её публичный метод, или нужно только события использовать для обмена информацией между элементами?

[Wolsh]

Просто пока у меня контроллер почти без дела простаивает

Это нормально. Был даже такой афоризм у борца с "Толстыми Тупыми Контроллерами" — "Лучший контроллер — пустой контроллер". Это старая холиварная тема, о причинах я уже как-то упоминал: БазаДанных - сервер - клиент. Нам такой MVC внутри одной .swf не нужен.

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

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

[Appleman]

Друзья! Двинулся дальше в разработке и серьёзно застрял (как обычно) Need help. Я уже раньше поднимал тему формулировки условий, но только теперь практически дошёл до этого момента. Итак, имеем по-прежнему мини-игру - схватку один-на-один в жанре текстового квеста, хотя для обсуждаемого вопроса это в данный момент не принципиально. В каждую фазу игрок выбирает одно из доступных действий. Мне видится следующая реализация. Планирую создать отдельный класс действия (да, я помню, что в отсутствие изменяемых свойств вполне вероятно, их удобнее будет реализовать статической таблицей, но пока точно удобнее классом), где "живут" значимые для игровой механики свойства. Будучи выбранным, нужный экземпляр отправляется в качестве аргумента в метод-обработчик модели, где будут обрабатываться его результаты. Но до этого этапа мне не дойти. Проблема в том, что условия доступности разных действий сильно варьируются и вообще достаточно разнообразны сами по себе. Например, чтобы действие было доступно для выбора, может одновременно требоваться определённый пол или раса персонажа, значение свойства или навыка, определённый предмет экипировки в наличии. А другое может иметь в числе условий значения каких-то свойств противника и, например, время суток. Естественно, все значения, фигурирующие в числе условий - это свойства тех или иных игровых объектов. Вопрос, как всё это на абстрактном уровне "уложить" в код. Я уверен, что данный вопрос многократно решён. Спасибо.

[ZergMaster]

самый очевидный вариант - это иметь в каждом действии функцию "доступность", которая будет сверяться с моделью по всем требуемым параметрам перед тем, как предложить себя игроку. Но, возможно, есть варианты покрасивше. Вконтакте api, например, помню, была интересная реализация проверки разрешений через 8ричные числа или как-то так. Может, кто подскажет.

[caseyryan]

Вконтакте api, например, помню, была интересная реализация проверки разрешений через 8ричные числа или как-то так. Может, кто подскажет.

Забавное название) На самом деле это называется "битовая маска"

п.с. Небольшой офтоп, но эта тема сама по себе уже превратилась в текстовый квест) Называется "догадайся о чем спрашивает автор". Слишком много текста. Вопросы надо как-то по-лаконичнее формулировать

[ZergMaster]

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

тема сама по себе уже превратилась в текстовый квест) Называется "догадайся о чем спрашивает автор"

+1 =)) тоже читаю посты автора, как ребусы)) Ну ничего, сейчас придет Wolsh и все подроообненько расскажет))

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

[Wolsh]

Не, ну я тоже могу только строить предположения)) Мне видится так, что на сцене нарисованы два чувака — Вражина и Герой, написано последнее действие Вражины (или целый лог действий) типа "Серый Волк плюнул в лицо Красной Шапочке" и дальше список вариантов действий Кра.Ша., один из которых должен выбрать Игрок. Мне вот только непонятно, этот список ИЗНАЧАЛЬНЫЙ, неотфильтрованный, он всегда вообще один и тот же? То есть в нем изначально записаны вообще ВСЕ варианты, возможные в игре? Или он индивидуальный для каждого эпизода "большого" сюжета? Если второе, то получается он должен поставляться вместе с квестом в виде скажем XML, типа

<action id="000001" name="Ударить ножом в глаз">
	<condition owner="self" prop="hasHand" value="true"/>
	<condition owner="self" prop="hasKnife" value="true"/>
	<condition owner="enemy" prop="hasEye" value="true"/>
	<condition owner="weather" prop="isNight" value="false"/>
	<result chanse="0.8" owner="enemy" prop="hasEye" value="false"/>
</action>

, а в первом случае его можно оформить как Класс, но тогда он должен включать в себя неимоверное кол-во действий и необходимых для них условий?

[Appleman]

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

п.с. Небольшой офтоп, но эта тема сама по себе уже превратилась в текстовый квест) Называется "догадайся о чем спрашивает автор". Слишком много текста. Вопросы надо как-то по-лаконичнее формулировать

Сорри, братва, если непонятно изъясняюсь. Хотя всегда наивно полагал, что с русским языком у меня полный порядок, раз взялся за текстовый квест. Хотел было пояснить, но действительно пришёл Wolsh и сделал это вместо меня.

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

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

Спасибо, интересно. Я почему-то думал наоборот, что в модели метод, а в экземпляре действия условия.

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

Не, ну я тоже могу только строить предположения)) Мне видится так, что на сцене нарисованы два чувака — Вражина и Герой, написано последнее действие Вражины (или целый лог действий) типа "Серый Волк плюнул в лицо Красной Шапочке" и дальше список вариантов действий Кра.Ша., один из которых должен выбрать Игрок.

Да, абсолютно верно. Именно так эта механика и выглядит. Одновременно под действие ещё меняется арт на бэкграунде, портреты героев, health-бары и т.п.

Мне вот только непонятно, этот список ИЗНАЧАЛЬНЫЙ, неотфильтрованный, он всегда вообще один и тот же? То есть в нем изначально записаны вообще ВСЕ варианты, возможные в игре? Или он индивидуальный для каждого эпизода "большого" сюжета?

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

Если второе, то получается он должен поставляться вместе с квестом в виде скажем XML, типа

<action id="000001" name="Ударить ножом в глаз">
	<condition owner="self" prop="hasHand" value="true"/>
	<condition owner="self" prop="hasKnife" value="true"/>
	<condition owner="enemy" prop="hasEye" value="true"/>
	<condition owner="weather" prop="isNight" value="false"/>
</action>

О! Вот это уже теплее А как от таких формулировок переходить непосредственно к проверке? Парсить с такой логикой, что если owner = self, то обращаться _player[hasHand], а если owner = enemy, то проверяем _eneme[hasEye]. Таким образом?

а в первом случае его можно оформить как Класс, но тогда он должен включать в себя неимоверное кол-во действий и необходимых для них условий?

По всей видимости, мы о разных классах говорил. Мне представляется класс Action, где будут храниться свойства, необходимые для игровых расчётов. Я думал там сделать свойство conditions: Array, где будет храниться похожая на приведённую тобой конструкция. А дальше модель перебирает все действия из массива и пробегается по их условиям. Если все выполняются, то экземпляр включается в диалог выбора, а если нет, то например, можно сделать кнопку неактивной и передать туда на всплывающую подсказку, чего конкретно не хватает, чтобы действие стало доступным.