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

[ZergMaster]

На деле это во многих случаях решается даже банальным поясняющим комментом в одну строчк

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

большинство как раз постараются усложнить работу следующему программисту

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

[Appleman]

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

 
			var action:Object =
			{
				id:"000001",
				name:"Ударить ножом в глаз",
				conditions:
				[
					{owner:"self", prop:"hasHand", value:true},
					{owner:"self", prop:"hasKnife", value:true},
					{owner:"enemy", prop:"hasEye", value:true},
					{owner:"weather", prop:"isNight", value:false}
				]	
			}

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

я хотел чуть назад вернуться. Начал писать условия, выходит пока лютое месиво - очень тяжело читать. Вспомнил предложение о создании отдельного класса для условий. Можно об этом поподробнее? Может я туплю опять, но мне понятно, что свойствами класса условий будет то, что сейчас является идентификаторами в обжектах: owner, prop, value. Такой класс создать несложно.

Но вот дальше как этим пользоваться? Заранее создавать экземпляры условий, записывать их в переменные с говорящими названиями и выдавать по идентификатору из класса-справочника?

[ZergMaster]

точно так же и пользоваться. Создание классов нужно для удобочитаемости и типизации, которая позволит IDE подсветить нужное и не даст проделать не нужное.

public class Action 
{
      pritvate var _id:String;
      pritvate var _name:String;
      pritvate var _conditions:Vector.<Condition>;
 
      public function Action(id:String, name:Sting, conditions:Vector.<Condition>)
     {
           _id = id;
           _name = name;
           _conditions = conditions;
     }
}
 
public class Condition
{
      pritvate var _owner:String;
      pritvate var _prop:String;
      pritvate var _value:Boolean;
 
      public function Condition(owner:String, prop:String, value:Boolean) 
      {
              _owner = owner;
              _prop = prop;
              _value = value;
      {
}
 
//исопльзование
 
var action:Action = new Action("000001", "Ударить ножом в глаз",
                                       new <Condition>[
                                                 new Condition("self", "hasHand", true),
                                                 new Condition("self", "hasHand", true),
                                                 new Condition("self", "hasHand", true),
                                                 new Condition("self", "hasHand", true),
                                                 new Condition("self", "hasHand", true),
                                                 ])

смысл в том, что так подсказки вылезают, по коду навигация упрощается и в целом православней выглядит.

[Appleman]

Ну чёрт его знает... Как-то не впечатляет. Как в концовке известного анекдота: "Е$%т как е%$ли, только бухгалтерии добавилось"

[Wolsh]

Я здесь за формализацию в класс Condition, конечно (с детства не люблю Обжекты).
Пока все просто, выглядит оно почти одинаково, конечно. Но все-таки инкапсуляция в класс позволит как-то узаконить свойства, а там глядишь и методы подтянутся. В частности, я бы рассмотрел возможность перенести метод test() в Condition, где ему было бы тепло и уютно среди своих. Опять же, появляется возможность расширения на подклассы с какими-то специфическими свойствами и собственными(!) алгоритмами проверки в override методе test(). Которые не нужно будет расписывать в Action и обновлять каждый раз когда придет в голову новая разновидность Условия. Это взгляд в прекрасное будущее.

Заранее создавать экземпляры условий, записывать их в переменные с говорящими названиями и выдавать по идентификатору из класса-справочника?

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

[Appleman]

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

В частности, я бы рассмотрел возможность перенести метод test() в Condition, где ему было бы тепло и уютно среди своих. Опять же, появляется возможность расширения на подклассы с какими-то специфическими свойствами и собственными(!) алгоритмами проверки в override методе test(). Которые не нужно будет расписывать в Action и обновлять каждый раз когда придет в голову новая разновидность Условия. Это взгляд в прекрасное будущее.

Спасибо, интересно. Подумаем...

Поймал себя на мысли, что из шаблона "стратегия", который вы с ZergMaster обоснованно рекомендовали мне взять за основу, после изъятия контекстов и интерфейсов стратегий, по сути ничего и не осталось. Только сам экземпляр Action или наследника, добавленный методом композиции в мою Модель в переменную action.

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

public class Action 
	{
		private var _actionData: ActionData;
		private var _attacker: Character;
		private var _defender: Character;
 
		public function Action (data: ActionData, attacker: Character, defender: Character) 
		{
 
		}
 
	}

Тогда с использованием единых "заготовок" мы можем сделать и вариант, когда герой даёт в лоб противнику, и наоборот. Достаточно просто передать персонажей в конструктор в другом порядке. что думаете?

Что касается метода test (attacker: Character, defender: Character), то он пока остался в классе Action фактически как транзитный. Ибо я точно знаю, что подобным образом проверять условия придётся не раз и не два в различных ситуациях, поэтому "зашивать" его в Action было бы недальновидно. Ничего пока лучше не придумал, чем сделать "статический" класс CheckActionConditions, специализирующийся на проверке условий Засылаю туда экземпляр Action и действующих лиц, обратно получаю true/false.

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

В общем, выходит, саму запись лучше не "причесать". Возможно, подобным образом имеет смысл наиболее типичные условия сохранять: проверка расы/пола и т.п. А что-то более специфическое уже записывать полностью.

[Wolsh]

Поймал себя на мысли, что из шаблона "стратегия" ... по сути ничего и не осталось.

Ну, я говорил, что реализовать Стратегию формально как в книжке не получится, жизнь внесет свои корректировки. Однако, это не правда, что "ничего не осталось". Вся Стратегия на месте. Ее слегка подрастянули, где то поднакачали силиконом, но в душе это она. При вызове какого-то метода какого-то объекта запускается РАЗНЫЙ алгоритм, выбранный из набора алгоритмов, инкапсулированных в объекты (здесь — Action), в соответствии с Контекстом (здесь — состояния свойств атакующего и защищающегося). То есть соблюдена вся суть паттерна Стратегия, кроме формальных нюансов синтаксиса вроде сладкой парочки setStrategy() + execute().

Достаточно просто передать персонажей в конструктор в другом порядке. что думаете?

Мне казалось это не просто очевидным, а так и задуманным. Я и не думал что ты собираешься дублировать все экшены на МашаБъетВасеНожомВГлаз и ВасяБъетМашеНожомВГлаз.

Что касается метода test (attacker: Character, defender: Character), то он пока остался в классе Action

Конечно он должен быть в классе Action ТОЖЕ. А в нем вызываться test() у всех Condition — возможно, Action даже захочет передать кондишенам что-то свое или (о боже) зачем-то сравнивать результаты двух кондишенов типа "если этот да, а этот нет, то..."

[Appleman]

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

Мне казалось это не просто очевидным, а так и задуманным. Я и не думал что ты собираешься дублировать все экшены на МашаБъетВасеНожомВГлаз и ВасяБъетМашеНожомВГлаз.

Ну да. Я в предыдущей реплике немного сместил акценты. Хотел спросить мнение об идее вынести в отдельный класс ActionData всю "статику", а класс Action сделать таким классом-"собирателем", буквально из действующих лиц и экземпляра нужного ActionData или его наследника. Вот в этом вопрос был.

Конечно он должен быть в классе Action ТОЖЕ. А в нем вызываться test() у всех Condition — возможно, Action даже захочет передать кондишенам что-то свое или (о боже) зачем-то сравнивать результаты двух кондишенов типа "если этот да, а этот нет, то..."

Вообще, ZergMaster и Wolsh, большое вам спасибо ещё раз за идеи и комментарии. Я наконец прочувствовал кайф от вынесения условий в отдельный класс. Оставил в супере только общие свойства: owner и propID, а например те же режимы сравнения (обычное равенство, или значение из диапазона и т.п.) реализовал в наследниках и переопределил там testCondition(). Теперь башка вообще не болит с выбором нужного алгоритма для разных случаев. И цепочки switch-ей с else-if-ами тоже нет. Очень здорово!

Единственное, что не очень понравилось, так это то, что в класс Condition приходит каждый раз "тащить" всё то, что непосредственно будет сравниваться - owner-ов свойств. И персонажи - ещё полбеды, они хоть в самом Action-е живут. Так ещё есть локация, какие-то текущие параметры модели... Вот что с этим делать, до конца непонятно Навскидку подумалось завести некий класс State, который будет хранить изменяемые параметры, напрямую не относящиеся ни к персонажам, ни к локации. И также передавать его, в test().

[Wolsh]

Что, реально так много условий, не связанных с персонажами? Что значит "локация" например? Что под водой нельзя стрелять из лука а ножом пырнуть можно? Ну ок, ладно. Допустим, в объекте ЛокацияИнфо можно хранить много разных данных, включая погоду и даже скрипя зубами дату-время (из которой можно определить зима или лето, ночь или день — как бы тоже локация, но во времени). Ну а что еще такого есть в игре, что не относилось бы ни к персонажам ни к миру, но при этом влияло бы на доступность действий? Хочу пример, чтоб понять, а то моей фантазии не хватает.

[Appleman]

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

Ну а что еще такого есть в игре, что не относилось бы ни к персонажам ни к миру, но при этом влияло бы на доступность действий? Хочу пример, чтоб понять, а то моей фантазии не хватает.

У меня пока нет как такового "мира", поэтому вопросы и возникают.

Я тут опять застрял. Пока успешно насоздавал игровых действий, научил Модель отбирать доступные, а Вью - раскладывать их по группам и обеспечивать навигацию пользователя. В общем, дошёл до момента выбора. Когда пользователь делает свой выбор, в контроллер летит выбранный им объект типа Action, который, в соответствие с используемым паттерном "стратегия", присваивается переменной модели _action и у неё сразу же запускается метод _action.initiate().

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

public class Action 
	{
		private var _actionData: ActionData; 	// Данные выполняемого действие
		private var _ch1: Character; 			// Первый персонаж
		private var _ch2: Character; 			// Второй персонаж
 
		public function Action(data: ActionData, character1: Character, character2: Character) 
		{
			_actionData = data;
			_ch1 = character1;
			_ch2 = character2;
			trace ("Создали действие по шаблону " + _actionData.actionID);
		}

Соответственно, Модель не "знает" что в том или ином случае нужно использовать KnifeActions, WalkAction или TalkAction.

Единственный, кто "знает" о специфике того или итого действия - это ActionData, т.к. она создаётся вручную. Но там, блин, нету персонажей, они только в момент создания Action появляются. Некого обсчитывать! Помогите плиз, как мне с этим справиться. Спасибо.