Войти
ПрограммированиеФорумИгровая логика и ИИ

Как можно реализовать диалоги с неписями в рпг? (22 стр)

Страницы: 121 22 23 2432 Следующая »
#315
(Правка: 22:23) 22:10, 24 ноя 2022

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

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

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

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

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

#316
23:11, 24 ноя 2022

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

+ Показать
#317
0:07, 25 ноя 2022

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

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

#318
1:10, 25 ноя 2022

FourGen

+ Показать

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
> Вот с таким можно
пилить игру несколько десятков лет и по итогу так ничего и не запилить.

#319
1:13, 25 ноя 2022

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

#320
3:21, 25 ноя 2022

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

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

#321
3:24, 25 ноя 2022

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

#322
7:03, 25 ноя 2022

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

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

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

#323
(Правка: 8:02) 7:55, 25 ноя 2022

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

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

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

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

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

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

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

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

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

#324
8:10, 25 ноя 2022

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

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

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

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

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

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

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

Далее по коду

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

#325
9:07, 25 ноя 2022

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

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

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

#326
9:11, 25 ноя 2022

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

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

#327
(Правка: 9:21) 9:20, 25 ноя 2022

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

#328
(Правка: 10:15) 10:01, 25 ноя 2022

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

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

struct Item
{
IntPtr[][] Params;
}

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

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

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

>samrrr

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

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

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

+ Показать
#329
(Правка: 11:47) 11:11, 25 ноя 2022

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

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

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

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

Страницы: 121 22 23 2432 Следующая »
ПрограммированиеФорумИгровая логика и ИИ