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

[Wolsh]

_character = new Character(false, false, true); // (hasHand:Boolean, hasEye:Boolean, hasKnife:Boolean)
_enemy = new Character(true, true, false);
 
var action: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>;
 
var selfConditions:XMLList = action.condition.(@owner=="self");
var enemyConditions:XMLList = action.condition.(@owner=="enemy");
 
for each(var cond:XML in selfConditions)
{
	if (_character[cond.@prop] == cond.@value) trace("pers", cond.@prop, "-- yes");
	else trace("pers", cond.@prop, "-- no");
}
 
for each(var condE:XML in enemyConditions)
{
	if (_enemy[condE.@prop] == condE.@value) trace("enemy", condE.@prop, "-- yes");
	else trace("enemy", condE.@prop, "-- no");
}

pers hasHand -- no
pers hasKnife -- yes
enemy hasEye -- yes

[Appleman]

Круто! Тот самый случай, когда с XML в три раза проще и технологичнее выходит. А есть обкатанный вариант, когда не по принципу "истина-ложь", а количественно сравнивается: "больше 5" или "меньше 2"?

[Wolsh]

<condition owner="self" mode="range" prop="level" min="12" max="80"/>

[Appleman]

Спасибо. Вот точно нужно подвязывать по ночам сидеть. Мозг уже не тот Чего только я себе не напридумывал, а всё решается просто и красиво.

Добавлено через 26 минут
Единственное, у меня какое-то в этом контексте отторжение вызывает XML. В том плане, что, например, файлы с фразами на нужном языке - это данные "внешние" по отношению к программе. А условия доступности действий - самые что ни на есть "потроха", которые неохота "подцеплять сбоку".

[Wolsh]

			_character = new Character(true, false, true); // (hasHand:Boolean, hasEye:Boolean, hasKnife:Boolean)
			_enemy = new Character(true, true, false);
 
			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}
				]	
			}
 
			var enabled:Boolean = true;
 
			for each(var cond:Object in action.conditions)
			{
				switch (cond.owner)
				{
					case "self" : if (_character[cond.prop] != cond.value) enabled = false;
					break;
					case "enemy" : if (_enemy[cond.prop] != cond.value) enabled = false;
					break;
				}	
			}
 
			trace(action.name, enabled ? "можно" : "нельзя");

[Appleman]

Спасибо, wolsh. Просто репозиторий какой-то мне устроил Возьму за основу.

[Wolsh]

И да, если принять во внимание что это действительно фактически основные для игры данные, наверное есть смысл сделать класс для "действия", а может даже и класс для "условия", чтобы не оформлять эту красоту в каких-то безродных обжектах. А там, глядишь, еще и методы какие-то завести можно будет, типа action.test(_character); Ну, или, я не знаю.. статический класс ActionManager с методом getEnabledActions, возвращающий массив (вектор) всех доступных экземпляров Action.. Только ему (методу) придется давать ссылки на всех возможных owner'ов.

[Appleman]

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

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

Собственно, вопрос, как посоветуете лучше сделать: продолжать добивать такие свойства в основной класс или создать новый класс, например, CharacterBattle, куда экземпляр Chatacter будет включён методом композиции и экземпляр которого будет создаваться при запуске мини-игры, и уже в него добавлять нужные свойства?

[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}
				]	
			}

Почти закончил программировать View, расставил всё на экране по местам, завязал на обновление модели. Скоро перехожу к core-геймплею. В связи с этим вернулся к вопросу формулировки условий. Метод, предложенный wolsh-ем, понятен и его работа вопросов не вызывает. Кроме одного. Сейчас все строчки условий связаны логическим "И". А как быть, если в какой-то строке появляется "ИЛИ"? То есть например, или ночь, или герой - гном Ситуация вполне типичная. Пока мне придумался только массив из обжектов в каждой строке, которые потом будут разбираться парсером. Но это слегка громоздко. Есть альтернативные мысли? Спасибо.

[Appleman]

Друзья! Продолжаю работу над своей игрой, а главное, освоение ООП, и у меня опять ООПа. Прошу помочь.
Создал класс с игровыми действиями. Он полностью "обезличен", т.к. механика действий по факту одинаковая для героя и противника. У меня в них фигурируют character1 и character2. Один имеет "активный" статус, т.е. атакует, другой - "пассивный", т.е. защищается. С условиями вроде тоже пока всё получается, как минимум, получилось их формализовать и записать в качестве свойств, "читабельных" для программы. Пока создал три разных экземпляра действий и запихал их в массив, доступный для Модели.

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

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

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