Перейти к контенту

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


Рекомендуемые сообщения

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

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

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

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

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

 

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

Ссылка на комментарий

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

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

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

Изменено пользователем dPlayer
Ссылка на комментарий

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

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

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

Вроде так...

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

Изменено пользователем nasar75
  • Нравится 4
  • Согласен 1

AMD Athlon II X2 250, NVIDIA GTS 450, RAM 8.0 GB, WIN 7/64  правки Золотой Шар

Ссылка на комментарий

 

 

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

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

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

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

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

как-то так.

  • Нравится 2
  • Согласен 1

Мод, где не бывает одинаковых путей - Судьба Зоны. (Лучшее, что у меня получилось на X-Ray) На базе модифицированного движка OGSR Engine.

Бывший мододел на X-Ray / Начинающий игродел на Unreal Engine. Программист.

AMD Ryzen 9 7950X (16 ядер, 32 потока, 5.75 ГГц); RTX 3080; 128 ГБ DDR5; Arctic Liquid Freezer II-420; 3 ТБ SSD PCIe 4.0; 4ТБ HDD.

Ссылка на комментарий

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

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

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

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

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

Восстановление здоровья: +1%
Это будет значить, что за секунду добавляется процент к общему здоровью ГГ?
radiation_restore_speed а это в чем лучше измерять? Также в процентах? Или какие-нибудь бэры, рады и прочее нарисовать? (ещё бы я в этом что-то понимал  :))
Собственно, сделав это будет нереально легко настраивать параметры для артефактов и, что самое главное, игрок когда посмотрит на все эти циферки будет понимать, чего от такого артефакта ждать.
Но, если сделать проценты в секунду, то из практически мертвого состояния за ~100 секунд показатель полностью восстановится/обнулится.
Это подходит далеко не для всех параметров, если при ношении артефакта ГГ получит полную шкалу радиации за ~ 1:40 секунд (причем не факт что он доживёт до момента заполнения этой шкалы.) это будет как минимум плохо. Это при том что 1% типа минимальная циферка после 0  :)  а может быть и 3, и 5, и 10%.
С технической точки зрения вопросов нет, благо есть исходники движка и подправить в нём коэффициенты труда не составит. Мне нужны Ваши идеи, как рассчитывать тот или иной показатель. Что бы это нравилось в первую очередь игроку. Ну или ткните куда-нибудь, если где-то это вменяемо оформлено.
Изменено пользователем Kondr48
Ссылка на комментарий

 

 

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

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

ed_rez.gif

c1f11b67ff360413e81b4e4dcf21eb41.jpg

Ссылка на комментарий

 

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

 

Ссылка на комментарий

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

 

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

Ссылка на комментарий

parts per millon же.

 

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

Изменено пользователем Dennis_Chikin
Ссылка на комментарий

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

  • Нравится 1
  • Согласен 1
Ссылка на комментарий

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

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

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

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

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

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

Изменено пользователем Kondr48
Ссылка на комментарий

@dsh

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

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

 

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

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

 

 

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

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

  • Нравится 1

ed_rez.gif

c1f11b67ff360413e81b4e4dcf21eb41.jpg

Ссылка на комментарий

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

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

Изменено пользователем Kondr48
Ссылка на комментарий

@Kondr48

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

time_factor = 10

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

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

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

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

Изменено пользователем ed_rez
  • Спасибо 1

ed_rez.gif

c1f11b67ff360413e81b4e4dcf21eb41.jpg

Ссылка на комментарий

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

  • Нравится 1
Ссылка на комментарий

@dsh

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

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

 

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

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

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

Изменено пользователем ed_rez
  • Спасибо 1
  • Согласен 1

ed_rez.gif

c1f11b67ff360413e81b4e4dcf21eb41.jpg

Ссылка на комментарий

Видимо я не совсем понял 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);
}
 

 

 

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

Изменено пользователем Kondr48
Ссылка на комментарий

@Kondr48

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

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

 

 

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

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

ed_rez.gif

c1f11b67ff360413e81b4e4dcf21eb41.jpg

Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...