Gameplay - как сделать ЭТО, чтобы ОНО всем нравилось ;)

[Dennis_Chikin 3 658]

Тема предназначена для разработчиков, а не для пользователей. Модерирование будет крайне жестким. Прежде, чем что-либо писать - прочитайте первый пост и примеры обсуждения. Изменено 24 Ноября 2014 пользователем Dennis_Chikin

[abramcumner 1 146]

Как думаете вы?

Получается тоже на тоже. Подорожала аптечка, подорожала пустышка, увеличилась награда за задание. Как раньше нашел артефакт, продал, купил аптечку; так и сейчас.

[Карлан 1 049]

Получается тоже на тоже. Подорожала аптечка, подорожала пустышка, увеличилась награда за задание. Как раньше нашел артефакт, продал, купил аптечку; так и сейчас.

Данный мой вопрос относился к дефицитам и только, но хорошо.

 

Я не соглашусь, точнее соглашусь только с тем, что это верно если бы были одни только денежные отношения. Объясню. В сталкере, как минимум, фигурируют какие-то примитивные услуги, товары, деньги. Теперь вспомним бородатый анекдот про сантехника, который говорил: "мне твой курс по барабану, моя работа как стоила пузырь, так она и будет стоить". Т.е. здесь мы существенно расширяем круг возможностей регулирования экономики, в некоторых случаях может не возрастать ни денежная, ни товарная награды. Цена торговца с течением времени будет отрываться от цены актора, это стимулирует тратить деньги и делать запасы, так как через день-другой твоя пустышка будет дефакто "пустышкой", т.е. она станет дороже (по деньгам), но в действительности (покупательная способность) она станет дешевле. Награда за задание тоже не сможет вот так вот просто взять и увеличится, каждый же закладывает какую-то часть ресурсов в этот, т.н. "наградной фонд", с какой стати он должен его, условно, каждые пять минут пересматривать? Никто этого делать не будет. Отсюда в какой-то момент времени обесценение этих услуг достигнет какой-то критической точки, когда эти награды нужно будет действительно пересматривать, но это будет не сразу. К тому же кто-то может необоснованно завышать/занижать цену. А какой-то мужик чего-то там меняет только на собачьи хвосты, цены не меняет, хвосты дорожают - мужик богатеет.

[dPlayer 470]

Имеется квест и ряд квестовых предметов, валяющихся там и сям. По истории, эти предметы валяются в Зоне давно, до начала похождений ГГ и имеют ощутимый вес. Указывать отметки на каждом болте не хочется. Как будет поступить правильнее:

-Заспавнить эти предметы с началом квеста. Тогда возникает вопросы типа "я тут 5 минут назад был и ничего не лежало", т.е. логика, целостность мира и восприятие игры будут пошатаны.

-Заспавнить предметы с начала игры. Тогда возникает вопрос, как быть, когда игрок подберёт их. Как уберечь его от потери ценного предмета, или, если предмет "квестовый", как объяснить, что ему придётся таскать найдённый на АТП 120-килограммовый мост от УАЗика всю игру аж до Припяти, где он потребуется по квесту.

Изменено 12 Декабря 2016 пользователем dPlayer

[_Val_ 2 225]

 

 

как быть

Для начала - не придумывать таких прикольных квестов...

[nasar75 3 868]

@dPlayer, может, напишу фигню, но таки напишу...

Сделать два предмета содинаковым визуалом, но разными конфигами (по типу бочек\канистр). Один "юзабельный" для ГГ (тот самый "квестовый"- который ГГ может забрать в рюкзак), а второй "неюзабельный" ( тяжелее раз в 10 (чтоб ГГ его не пинал), нельзя поднять\взять в рюкзак).

Спавнить в начале игры "неюзабельный", а в нужный момент давать ГГ инфу ("ты, поди, уже видел его на АТП" или мысли вслух "Где ж я его видел? Не на АТП ли..."), удалять первый предмет и спавнить второй, "юзабельный".

Вроде так...

Пока писал, еще бредовая идея пришла. Нашел предмет - пришла смс("мысли ГГ") - "Интересная фигня, может пригодится. Надо её приныкать..." И цену предмету сделать в ноль -чтобы не было соблазна продать (или цену хорошую, но добавить в исключения продажи)

Изменено 13 Декабря 2016 пользователем nasar75

[Zander_driver 10 333]

 

 

Сделать два предмета с одинаковым визуалом, но разными конфигами

Дополню, как я бы решал подобные задачи =)

1 предмет - физ.объект с указанным визуалом, т. не-инвентарный предмет вообще. Прикреплен к террейну за кость модели, так что ни сдвинуть, ни взять, ни уничтожить или куда-то деть его нельзя.

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

2 предмет - инвентарный, с таким же визуалом. Когда ГГ по квесту жмакнет F на первом предмете, первый предмет удаляется, а второй спавнится актору в рюкзак. До тех пор первый лежит как нерушимая недвижимость и по нажиманию F лишь проверяет, что "еще не время".

как-то так.

[Kondr48 314]

Не знаю, наверное это наиболее подходящая тема. Что можно придумать со свойствами артефактов?) Как-то хотелось бы показатели подправить.

Привожу на примерах.

health_restore_speed - это скорость восстановления здоровья. По идее логично считать в процентах. Мы же увеличиваем эту скорость. Следовательно, при ста процентах здоровье должно восполниться мгновенно. Ну и, соответственно, при -100 мгновенно убить ГГ. (кому бы оно надо было  )

Но за какое время его восстанавливать? Этот процент, два или три? За секунду?

Например, если у артефакта в свойствах написано:

Восстановление здоровья: +1%

Это будет значить, что за секунду добавляется процент к общему здоровью ГГ?

radiation_restore_speed а это в чем лучше измерять? Также в процентах? Или какие-нибудь бэры, рады и прочее нарисовать? (ещё бы я в этом что-то понимал  )

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

Но, если сделать проценты в секунду, то из практически мертвого состояния за ~100 секунд показатель полностью восстановится/обнулится.

Это подходит далеко не для всех параметров, если при ношении артефакта ГГ получит полную шкалу радиации за ~ 1:40 секунд (причем не факт что он доживёт до момента заполнения этой шкалы.) это будет как минимум плохо. Это при том что 1% типа минимальная циферка после 0    а может быть и 3, и 5, и 10%.

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

Изменено 15 Февраля 2017 пользователем Kondr48

[ed_rez 16 109]

 

 

хотелось бы показатели подправить.

Изначально нужно какие рычаги создать для управления параметра скорости течения времени из конфигуратора. От этого параметра приходится делать перерасчет коэффициента влияний на ГГ, которые движком вычисляются и приводит к 10 тысячам % при уменьшении скорости течения времени. Суть текста такова, что параметры отталкиваются от скорости течения времени, как сейчас, но в видимых параметрах была бы разумная единица влияния на ГГ, а не 10- или 100 тыс. %.

[Kondr48 314]

 

ed_rez, вот об этом и речь. Нужны разумные единицы влияния. Собственно по ним мне и нужны идеи. Какой показатель с течением времени как должен на ГГ действовать.

 

[dsh 3 824]

@Kondr48, а чем не устраивает текущее? +1% к скорости восстановления здоровья означает, что скорость восстановления здоровья увеличится на 1%. Вроде вполне понятная штука.

 

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

[Dennis_Chikin 3 658]

parts per millon же.

 

"+1% к скорости восстановления здоровья" - ну или так: позволяет, действительно, не привязываться к времени.

Изменено 15 Февраля 2017 пользователем Dennis_Chikin

[dsh 3 824]

@Kondr48, если менять, то я бы поменял только способ задания скоростей восстановления и т.п. Что бы не в абсолютных величинах задавать, как сейчас, а в процентах от соотв. параметров актора. Это упростит настройку и поддержку, что бы при изменении параметров актора не нужно было пересчитывать все артефакты.

[Kondr48 314]

а чем не устраивает текущее? +1% к скорости восстановления здоровья означает, что скорость восстановления здоровья увеличится на 1%

Ну как минимум тем, что в конфигах там никакими процентами не пахнет, задаются абстрактные 0,0002 и т. п. Мб это только на исходниках так, но сейчас там при выведении свойств артефакта показатель просто умножается на 100, т. е. те же 0,0002 * 100 = 0,02% ~= 0% последнее и выводится. А там же не ноль, здоровье то будет восстанавливаться.

 если менять, то я бы поменял только способ задания скоростей восстановления и т.п. Что бы не в абсолютных величинах задавать, как сейчас, а в процентах от соотв. параметров актора.

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

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

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

Изменено 15 Февраля 2017 пользователем Kondr48

[ed_rez 16 109]

@dsh, 

именно это и имелось ввиду. 

Одно не понятно, как 

 

не привязываться к времени

не привязывать к времени? Необходимо какое-то условие, от чего считать. Какое условие будет тогда?

 

 

Нужны разумные единицы влияния

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

[Kondr48 314]

если была бы возможность проводить перерасчет в конфигураторе

Я никак не пойму, что значит перерасчет в конфигураторе. 

Изменено 15 Февраля 2017 пользователем Kondr48

[ed_rez 16 109]

@Kondr48, 

каждый игрок устанавливает свою скорость течения времени. При 

time_factor = 10

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

И расчет не такой, что коэффициент умножается просто на 100, чтобы получить %. А совсем иначе, правда я не забивал себе голову, какая у ПЫС формула. Но уверен, что связаны коэффициент, скорость течения времени.

Ладно, как пишет @dsh, что актор пересчитать с параметрами зависящими от течения времени- это пустяк. Проблема не в перерасчете, а в выводе полной пурги в виде 10 и 100 тыс % после перерасчета коэффициентов отталкиваясь от новой скорости течения времени.

Наверно я сильно заворачиваю, это я умею. )) Я надеюсь, что сейчас раскрыл свою мысль.

Изменено 15 Февраля 2017 пользователем ed_rez

[dsh 3 824]

@ed_rez, ну, если каждый лезет менять тайм фактор - это уже ни в какие рамки. Вот кто лезет, тут и пусть разгребает. Если на это закладываться, тогда действие артефактов нужно в реальном времени делать, а не в игровом. Правда тогда нужно будет специальным образом сон обрабатывать.

[ed_rez 16 109]

@dsh, 

я не про ковыряльщиков проектов. Я исхожу из собственных задач. Пример, ну не нравится мне течение времени, что оно такое быстрое, хочу в проекте сделать медленнее. Актор пересчитал, нет проблем, я этих параметров нигде вижу. Однако после перерасчета под новое течение времени, вылазят гадости в % в свойствах артефактов. Все работает от нового течения времени по тем параметрам, как пересчитал. Но вылазит пакость, где был процент при 10 (тайм), к примеру, 50%, то при 5 (тайм), сохраняя тот же вариант влияния на ГГ- процент влазит в десятки тысяч процентов. Что за формула такая!? Если в 2 раза уменьшил скорость, то логично должно быть усиление в 2 раза влияния на ГГ. Но нет, все не так. 

Видимо я не совсем понял @Kondr48-а и он иную проблему рассматривает. В общем, я высказал то, с чем сам столкнулся. Да, личная хотелка, да, самому решать- тут не в этом дело. Суть такова, если я понял так, как сам описываю и у кого-то есть возможность или желание что-то изменить. А если уже менять, то, возможно, моя писанина пригодится. 

 

Если в 2 раза уменьшил скорость, то логично должно быть усиление в 2 раза влияния на ГГ.

Я вообще не поднял бы вопрос, если просходил бы перерасчет % (видимого в артах) в столько раз, но в обратную сторону.

Уменьшил скорость в Х раз, то увеличил параметры артефактов (связанные с течением..) в Х раз. И мои 50% (из примера) превратились бы в 100% и у меня даже в мыслях не было, чтобы написать об этом.

Изменено 15 Февраля 2017 пользователем ed_rez

[Kondr48 314]

Видимо я не совсем понял Kondr48-а и он иную проблему рассматривает. В общем, я высказал то, с чем сам столкнулся. Да, личная хотелка, да, самому решать- тут не в этом дело.

Ну не то чтобы иную, в целом именно её, хочется переписать расчёт артефактов так чтобы удобно было настраивать их модмейкеру и всё было более чем ясно для игрока.

Там в движке вообще какая-то непонятная магия в свойствах артефактов на самом деле, вроде и на первый взгляд как-то логично, но сделано довольно странно. Свойства из конфига артефакта делятся на некие соответствующие у актора, потом это всё умножается на 100. Потом идут дальнейшие деления / умножения для конкретных свойств. Например кровотечение потом опять делится на 100, и выходит что цифра должна выводиться прямо из конфига?

#include "stdafx.h"
#include "ui_af_params.h"
#include "UIStatic.h"
#include "../object_broker.h"
#include "../Artifact.h"
#include "../Actor.h"
#include "../ActorCondition.h"
#include "UIXmlInit.h"

CUIArtefactParams::CUIArtefactParams()
{
	Memory.mem_fill			(m_info_items, 0, sizeof(m_info_items));
}

CUIArtefactParams::~CUIArtefactParams()
{
	for(u32 i=_item_start; i<_max_item_index; ++i)
	{
		CUIStatic* _s			= m_info_items[i];
		xr_delete				(_s);
	}
}

LPCSTR af_item_sect_names[] = {
	"health_restore_speed",
	"radiation_restore_speed",
	"satiety_restore_speed",
	"power_restore_speed",
	"bleeding_restore_speed",
	
	"burn_immunity",
	"strike_immunity",
	"shock_immunity",
	"wound_immunity",		
	"radiation_immunity",
	"telepatic_immunity",
	"chemical_burn_immunity",
	"explosion_immunity",
	"fire_wound_immunity",
};

LPCSTR af_item_param_names[] = {
	"ui_inv_health",
	"ui_inv_radiation",
	"ui_inv_satiety",
	"ui_inv_power",
	"ui_inv_bleeding",

	"ui_inv_outfit_burn_protection",			// "(burn_imm)",
	"ui_inv_outfit_strike_protection",			// "(strike_imm)",
	"ui_inv_outfit_shock_protection",			// "(shock_imm)",
	"ui_inv_outfit_wound_protection",			// "(wound_imm)",
	"ui_inv_outfit_radiation_protection",		// "(radiation_imm)",
	"ui_inv_outfit_telepatic_protection",		// "(telepatic_imm)",
	"ui_inv_outfit_chemical_burn_protection",	// "(chemical_burn_imm)",
	"ui_inv_outfit_explosion_protection",		// "(explosion_imm)",
	"ui_inv_outfit_fire_wound_protection",		// "(fire_wound_imm)",
};

LPCSTR af_actor_param_names[]={
	"satiety_health_v",
	"radiation_v",
	"satiety_v",
	"satiety_power_v",
	"wound_incarnation_v",
};
#ifdef AF_SHOW_DYNAMIC_PARAMS
float CArtefact::* af_prop_offsets[] = {
	&CArtefact::m_fHealthRestoreSpeed,
	&CArtefact::m_fRadiationRestoreSpeed,
	&CArtefact::m_fSatietyRestoreSpeed,
	&CArtefact::m_fPowerRestoreSpeed,
	&CArtefact::m_fBleedingRestoreSpeed
};
#endif



void CUIArtefactParams::InitFromXml(CUIXml& xml_doc)
{
	LPCSTR _base				= "af_params";
	if (!xml_doc.NavigateToNode(_base, 0))	return;

	string256					_buff;
	CUIXmlInit::InitWindow		(xml_doc, _base, 0, this);

	for(u32 i=_item_start; i<_max_item_index; ++i)
	{
		m_info_items[i]			= xr_new<CUIStatic>();
		CUIStatic* _s			= m_info_items[i];
		_s->SetAutoDelete		(false);
		strconcat				(sizeof(_buff),_buff, _base, ":static_", af_item_sect_names[i]);
		CUIXmlInit::InitStatic	(xml_doc, _buff,	0, _s);
	}
}

bool CUIArtefactParams::Check(const shared_str& af_section)
{
	return !!pSettings->line_exist(af_section, "af_actor_properties");
}
#include "../string_table.h"
void CUIArtefactParams::SetInfo(CGameObject *obj)
{	
	CArtefact *art = smart_cast<CArtefact*> (obj);
	R_ASSERT2(art, "object is not CArtefact");
	const shared_str& af_section = art->cNameSect();
	CActor *pActor = Actor();
	if (!pActor) return;

	string128					_buff;
	float						_h = 0.0f;
	DetachAll					();
	for(u32 i=_item_start; i<_max_item_index; ++i)
	{
		CUIStatic* _s			= m_info_items[i];

		float					_val;
		if(i<_max_item_index1)
		{
#ifdef AF_SHOW_DYNAMIC_PARAMS
			float _actor_val	= pActor->conditions().GetParamByName(af_actor_param_names[i]);			
			float CArtefact::* pRestoreSpeed = af_prop_offsets[i];
			_val = (art->*pRestoreSpeed); // alpet: используется указатель на данные класса
#else
			_val				= pSettings->r_float	(af_section, af_item_sect_names[i]);
			float _actor_val	= pSettings->r_float	("actor_condition", af_actor_param_names[i]);
#endif
			if					(fis_zero(_val))				continue;
			
			_val				= (_val/_actor_val)*100.0f;
		}else
		{
#ifdef AF_SHOW_DYNAMIC_PARAMS			
			u32 idx = i - _max_item_index1;  // absorbation index			 
			_val = art->m_ArtefactHitImmunities.immunities()[idx]; // real absorbation values			
#else
			shared_str _sect	= pSettings->r_string(af_section, "hit_absorbation_sect");
			_val				= pSettings->r_float(_sect, af_item_sect_names[i]);
#endif
			if					(fsimilar(_val, 1.0f))				continue;
			_val				= (1.0f - _val);
			_val				*= 100.0f;

		}
		LPCSTR _sn = "%";
		if(i==_item_radiation_restore_speed || i==_item_power_restore_speed)
		{
			_val				/= 100.0f;
			_sn					= "";
		}

		LPCSTR _color = (_val>0)?"%c[green]":"%c[red]";
		
		if(i==_item_bleeding_restore_speed)
			_val		*=	-1.0f;

		if(i==_item_bleeding_restore_speed || i==_item_radiation_restore_speed)
			_color = (_val>0)?"%c[red]":"%c[green]";


		sprintf_s					(	_buff, "%s %s %+.0f %s", 
									CStringTable().translate(af_item_param_names[i]).c_str(), 
									_color, 
									_val, 
									_sn);
		_s->SetText				(_buff);
		_s->SetWndPos			(_s->GetWndPos().x, _h);
		_h						+= _s->GetWndSize().y;
		AttachChild				(_s);
	}
	SetHeight					(_h);
}
 

 

 

Собственно, из этого обсуждения я уже кое-что для себя почерпнул), осталось только разобраться со здоровьем и кровотечением. Собственно, к каким единицам времени их лучше привязать? % в реальную секунду или игровую минуту? Или, может быть, реальную минуту.

Изменено 15 Февраля 2017 пользователем Kondr48

[ed_rez 16 109]

@Kondr48, 

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

Из r180 мне ни черта не понятно, не суть. Но из написанного понимаю, что в движке есть только единое влияние, которое собирается по всем параметрам, как ГГ, так и сторонних (артефакты, аномальные зоны,...). Вот тут хотелось бы увидеть формулу, математическую, как ПЫС высчитывали, чтобы не потерять все параметры в создании новой формулы. Где последнее, я думаю, что не сложно будет вывести и сделать универсальной для всех тайм_факторов, но отталкиваясь от реального времени, если такое возможно.

 

 

в реальную секунду или игровую минуту? Или, может быть, реальную минуту.

А как высчитывали ПЫС, от этого и плясать. Думается мне, что каждую реальную секунду. Иначе будет "влияние" накапливаться таки сильно за минуту и приведет к резким изменениям состояния ГГ. Я так понимаю, но представления не имею, как сейчас высчитывает движок, поэтому лишь математическое предположение.