Как можно реализовать диалоги с неписями в рпг? (22 стр) / Игровая логика и ИИ / Форум / Программирование игр / GameDev.ru

>Jeners
Да я знаю, уже говорил, мне так не наглядно привык так.
Когда инициализируешь полторы сотни массивов вручную имитируя загрузку, мне как-то не нравится считать номера строчек и прочее. Так проще перематывать в нужное место.

то тут можно взять Dictionary

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

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

Куда куда, ОДНО место в коде всего ОДНО, где ведется подсчет денег.

Jeners
Постоялец

#316
23:11, 24 ноя 2022

FourGen
Попробую объяснить иначе

+ Показать

− Скрыть

Есть класс Item
В нем например есть свойства
string Name; int Price;

Допустим нам нужно описать некоторые предметы с помощью этого класса.

Как это можно сделать? Можно сделать например просто массив данных

Item [] Items = new Item[]
{
  new Item("Меч", 100),
  new Item("Броня", 200),
};

К данным мы будем обращаться исключительно по индексу в массиве, т.е. что-то типо

if ( Items[0].Price > 100)
  {
  }

Конечно понятно что можно запомнить все индексы и что они обозначают, но с точки зрения удобства чтения кода - это не удобно. Код менее понятен тупо.

Теперь тоже самое но через словарь

Dictionary<string,Item>Items = new Dictionary<string,Item>
{
  {  "Меч",  new Item("Меч", 100)},
  {  "Броня"  new Item("Броня", 200)},
};

if ( Items["Меч"].Price > 100)
  {
  }

Код стал гораздо более читабельным, не так ли?

Так же очень неплохо будет завести названия в константы

public static class ItemNames
{
  public const string Sword = "Меч";
  public const string Armor ="Броня";
}

А еще, можно создавать словари на основе списков и других объектов реализующих интерфейс IEnumerable
Т.е. инициализируем код следующим образом

Dictionary<string,Item>Items = new string []
{
  new Item(ItemNames.Sword , 100),
  new Item(ItemNames.Armor , 200)
}.ToDictionary(x=> x.Name);

if ( Items[ItemNames.Sword].Price > 100)
  {
  }

Так же очень неплохо вынести например часть предметов в константный вид

public static class Items
{
  public static Item Sword = new Item(ItemNames.Sword,100);

  puplic static Dictionary<string,Item>Items = new string []
  {
    Sword,
    new Item(ItemNames.Armor , 200)
  }.ToDictionary(x=> x.Name);
}

И код стал еще более удобным

if ( Items.Sword.Price > 100)
  {
  }

В общем это все чисто для того чтобы просто подумать о том как сделать код более читабельным

FourGen
Постоялец

#317
0:07, 25 ноя 2022

>Jeners
Если для меня, то нет не стало более читаемым. Наплодили кучу несвязного кода вот и все. Мастабированию такой подход не подлежит (адекватному). Но я с ооп не дружу, может не прав.

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

samrrr
Постоялец

#318
1:10, 25 ноя 2022

FourGen

+ Показать

− Скрыть

//А ВОТ УДАЛЕНИЕ ДЕНЕГ ДЕЛАЕТСЯ ТУТ, А НЕ ОТ БАЛДЫ В КОДЕ, КАК ВЫ ПОКАЗЫВАЕТЕ
private void DelMoney(int ItemIndex)
{
int NeedMoneyIndex = GetItemMoneyTypeByItemIndex(ItemIndex);
ParamsScript.BaseCharacterMoney[GetItemMoneyTypeByItemIndex(ItemIndex)].Value -= ParamsScript.BaseItemsList[ItemIndex].ItemPrice;
Debug.Log("После покупки предмета у персонажа осталось этого вида денег: " + ParamsScript.BaseCharacterMoney[GetItemMoneyTypeByItemIndex(ItemIndex)].Value);
}

Так смотри, есть 2 подхода(вообще их более 2 и их можно комбинировать) к программированию чего-либо.

Предположим у меня обычная игра, простая сингл плеер игруля. В ней есть игрок у него инвентарь и какое-то число золотых. Тоесть то-же что в Assaseen Creed, дефолтный набор для большинства игр.

Как я буду такое реализовывать:

1) Основа данные, остальное идёт поверх них (ECS например)

struct PlayerData{
  int money = 0; // Золотых у игрока
  std::vector<Item> items; // Инвентарь
};

GetGameInstanceSubsystem<PlayerData>().money += 42;

Когда мне нужно изменить значение денег у игрока я меняю значение, просто и работает. Тут просто нечему ломаться.

2) Объектный подход(ООП)

class PlayerData{
public:
  void SetMoney(int money){this->money=money;}
  int GetMoney(){return money;}
  int AddMoney(int money){this->money+=money;}
private:
  int money = 0; // Золотых у игрока
  std::vector<Item> items; // Инвентарь
};

auto Player = GetGameInstanceSubsystem<PlayerData>();
Player.SetMoney(Player.GetMoney()+42);

или

GetGameInstanceSubsystem<PlayerData>().AddMoney(42);

Тут я закрываю доступ из вне и даю его только из внутренностей класса.

В твоём случае в C# придумали проперти, чтобы работать с деньгами так, какбудто это просто переменная.

FourGen
> ParamsScript.cs
Это хороший пример как не надо делать. Ты изначально в игру закладываешь слишком много. Там где я поставлю одну строчку, тебе приходится написать 100 чтобы получить тот-же результат. Это называется оверинженеринг, когда ты закладываешь слишком много возможностей расширения которые тебе не нужны.

Вот например твой MoneyScript.cs

    public bool InitializationMoneyScript(ParamsScript ParamsScriptLinc)

Это походу какая то чушь от юньки.

    //Функция получения Названия типа денег по Index
    public string GetMoneyNameByType(int MoneyType)

Этого не должно быть в MoneyScript.cs это не его ответственность вообще. Сопоставлением MoneyType и его локализированным именем должна заниматься EngineSubsystem в которой будет хеш таблица TMap<int, MoneyTypeInfo> MoneyTypesMap
А в этом MoneyTypeInfo будут нужные поля

struct MoneyTypeInfo{
  FText Name;
  FTexture Icon;
  FColor TextColor;
}

    private int GetItemMoneyTypeByItemIndex(int ItemIndex)
    {                
        return ParamsScript.BaseItemsList[ItemIndex].MoneyType;
    }

Нафига? Если тебе нужно получить стоимость предмета то назови нормально GetItemCost и верни ItemCost. И опять это не ответственность этого класса.

    //Установка базовых параметров Money для персонажа
    public bool SetBaseCharacterMoney()

Это не моней должен сам выставлять стартовые значения, а GameMode.

    public bool CheckItemPrice(int ItemIndex);

Всё хорошо в этом методе, но только он неправильно работает.

if (ParamsScript.PlayerParams.Money[NeedMoneyIndex].Value > ParamsScript.BaseItemsList[ItemIndex].ItemPrice)

Тут должно быть >=

    //А ВОТ УДАЛЕНИЕ ДЕНЕГ ДЕЛАЕТСЯ ТУТ, А НЕ ОТ БАЛДЫ В КОДЕ, КАК ВЫ ПОКАЗЫВАЕТЕ   
    private void DelMoney(int ItemIndex)

А в этой функции ты опять сделал лишнее. Должно было быть:

private void DelMoney(int MoneyType, int Cost){
  if(ParamsScript.BaseCharacterMoney[MoneyType].Value < Cost){
    Debug.Log("Как это произошло?");
  }
  ParamsScript.BaseCharacterMoney[MoneyType].Value -= Cost;
}

FourGen
> Вот с таким можно
пилить игру несколько десятков лет и по итогу так ничего и не запилить.

samrrr
Постоялец

#319
1:13, 25 ноя 2022

Jeners
> И код стал еще более удобным
>
> if ( Items.Sword.Price > 100)
> {
> }
Тут ты захардкодил Sword а должно быть Items["Sword"].Price

RikiTikiTak
Постоялец

#320
3:21, 25 ноя 2022

Super_inoy
> Так не должно быть, это зашквар зашкварный. За то что не можешь определиться с
> выбором должно быть наказание в виде очень сложного прохождения.
> А любые лимиты искусственные - убогая херота.
РПГ это игра про выбор, всем угодить нельзя. А вот про лимиты я не понял, пример приведите. Во всех играх ограничения есть, в песочницах их меньше.

Super_inoy
> И это плохо, точнее само по себе мог пройти хорошо, а вот то что пройти легко -
> плохо.
> С запоротой прокачкой все должно превращаться в ад вида - получи 0 урона за час
> танцев(а по другому тут это не назвать) с боссом, иначе ваншотнет.
> По сути - распыление скиллов на всякий мусор нерелевантный должно делать из
> игры на нормале игру на ультранайтмаре, вот это годный подход.
> А ограничения не нужны. Те же прозрачные стены, только не в мире, а в системе
> прокачки, фу такое убожество поощрять.
В хардкорные игры это в основном партийные, 1 убогий персонаж, остальные вытягивают. В готике и морровинде нельзя запороть с прокачкой и подобных играх. Соулс лаки или как их там называют, я в расчёт не беру, это не моё. В невервинтере 1 тяжеловато с запоротой прокачкой, но там напарника орка взять можно и он вытягивает.
Что значит поощрять такое — это нормальный классический подход в РПГ, есть еще казуальный подход, как в киберпанке и пиларсах. ДнД система она вся такая, да и подавляющие большинство других тоже.
Такое ощущения что вы РПГ только на ютюбе видели.

skalogryz
Участник

#321
3:24, 25 ноя 2022

RikiTikiTak
> как в киберпанке и пиларсах. ДнД система она вся такая
Киберпанк - днд что ли?

Jeners
Постоялец

#322
7:03, 25 ноя 2022

samrrr
Нет не должно быть. В некоторых случаях удобно делать объекты константными.

Может именно с классом Item это не лучший вариант, но например при описание месяцев (самый простой пример) Удобно все 12 месяцев сделать константными (а так же добавить возможность итерации).

Ну и в целом каждому свое. Итерации нужная штука но иногда бывает так что объект из коллекции играет некоторую важную роль и его неплохо было бы сделать enum like

FourGen
Постоялец

#323
7:55, 25 ноя 2022

>samrrr
У вас вопрос какой? Как реализовать диалоги, причем так, что бы можно было реагировать на любые события?
Это чушь и не будет работать?

Тут ты захардкодил

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

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

Вы слово "меч" воспринимаете, как "меч", а я как текстовое поле находящее по индексу и вы не понимаете разницы между вашим подходом и моим.

Оверинженеринга тут то же нет, это просто пример реализации масштабируемости, а не красивые и понятные присвоения имен, отделение задание переменных в разных классах друг от друга, что бы более проще и красиво было, но с потерей связанности (так как не знают как после вынесения в отдельных класс переменных связать их с отальным, что бы ничего не потерялось, а это лишняя работа)

Инициализация - это просто у меня название функции.

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

UPD
Хотя если надо можно и поломать вашу красивую в запись в словари превратив ее в кашу.

Jeners
Постоялец

#324
8:10, 25 ноя 2022

FourGen
Это не косяк. Может с типом Item это не лучший пример так как просто эту сущность все воспринимают по своему.

В общем такой подход удобен когда нужно описывать некоторые типы.

Самый простой пример - страны.

Пишем класс Country в нем - имя страны, валюта, язык, и.т.п.

Страны например в свою очередь предопрделены. В какой структуре их лучше описать? Массив? Словарь?

Я нахожу что описание таких данных удобно делать в виде статического класса с статическими полями

Что-то типо
public static class Countries
{
public static class Country Russia = new Country(...)
}

Далее по коду

if (npc.Country == Countries.Russia)
{
...
}

samrrr
Постоялец

#325
9:07, 25 ноя 2022

FourGen
> Вы слово "меч" воспринимаете, как "меч", а я как текстовое поле находящее по
> индексу и вы не понимаете разницы между вашим подходом и моим.
Потомучто это не имеет значения, я могу использовать строки вместо индексов, потомучто это удобнее.

FourGen
> Оверинженеринга тут то же нет
Тогда покажи готовую игру, за несколько лет ты же смог сделать хоть одну с таким подходом?

Jeners
Проблема твоего подхода это то, что чтобы добавить ещё 1 элемент приходится перекомпилировать код.

samrrr
Постоялец

#326
9:11, 25 ноя 2022

FourGen
> Это чушь и не будет работать?
Чушь более чем наполовину. Работать будет, но от любых изменений оно посыпется, и надо будет по 10-20 часов искать где сломалось. Мне такое решение не подходит.

А всё от того что решил игнорить SOLID.

Jeners
Постоялец

#327
9:20, 25 ноя 2022

samrrr
Лямбды тоже нужно компилировать) Я думал мы вещаем за реализацию диалогов в коде. А если нужно решение оторваное от компиляции но при этом достаточно гибкое - скрипты

FourGen
Постоялец

#328
10:01, 25 ноя 2022

>samrrr
Посыплется у вас, так как вы не умеете работать с индексами.
Указатели вы то же пихаете в словари связывая со строками, на которые они указывают, что бы было более читаемо?

Вот вам новый класс Item, если задаться целью сделать еще более масштабируемо.

struct Item
{
IntPtr[][] Params;
}

Присваивайте в словари все красиво и используйте в коде все красиво.

и надо будет по 10-20 часов искать где сломалось. Мне такое решение не подходит.

Что бы этого не было, надо делать не, как проще и красивее, а как надежнее у меня ошибку найти 2 минуты.

>samrrr

Тогда покажи готовую игру

Не покажу. Делаю. Еще не реализован весь минимально требуемый функционал.

UPD
Но я делаю, вот почти допилил установку двигателей

+ Показать

kkolyan
Участник

#329
11:11, 25 ноя 2022

FourGen
> вы не умеете работать с индексами
если вот это:

    private void SetDefaultItemsNames()
    {
        ItemsNames = new string[2];
        ItemsNames[0] = DefaultTexts[13];
        ItemsNames[1] = DefaultTexts[14];
    }

умение работать с индексами, то не уметь лучше чем уметь.

То, что вы не дали константам имена (безымянные константы - тоже константы) - не делает ваще приложение ничуть масштабируемей.