⚡⚡⚡ Полезные ссылки ⚡⚡⚡ 🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал (тут инфу про запись на курс можно получиться быстрее всех) 🔎 boosty.to/yakovlevgamedev - ссылка на бусти (тут можно поддержать канал, выход новых видео и даже получить эксклюзивные ништяки) 🔎 ua-cam.com/channels/C-hfECZdghe_QNAJzztHEg.html - ссылка на канал моего младшего брата (подпишись если не сложно)
Хароооош, видео то что надо. Вроде и знал что-то про инкопсуляцию но вот некоторые моментики подчерпнул. Например "не надо выдавать наружу что-то с публичным интерфейсом" - звучит хорошо. Держи лайк)
выносливость -= угол подъёма(подниматься медленнее и тяжелее, особенно при 90: вверх по скале-веревке) +(скорость передвижения(от направления и положения тела = ползать со скоростью бега не получится, а на карачках и задом на перед = наиболее затратное и медленное)*груз) +(температура окружающей среды-температура тела) + боль(множитель трат выносливости ) или число действий*0.2(чем больше действий за н-времени,тем больше тратится на каждое последующее) выносливость += само до 0.7 здоровья за Н-времени оперевшись на стенку /после бега(питьё, ограниченное скоростью питья и переваривания с размером желудка, при равном-большем рвота, а при равном и беге/драке = рвота) /от усталости(сном в Н-часов, в зависимости от состояния нпс, если он примет бодрящее вещество, то усталость=0, но через Н-времени интоксикация повлияет(после приема +интоксикация на все время влияния вещества, уменьшая здоровье, голод,жажду и положительное воздействие питья/пищи))
грузоподъемность = рост + физ.кондиция(мышцы/жир)(только от мышц +грузоподъемность ) рост даёт потенциальную скорость бега от размаха ног. скорость +физ.кондиции = стартовая + типы питания + Н-действий за Н-время(питание поддерживает текущие) жир даёт -голода/размер желудка и -выносливости с +сопротивляемостьХолоду мышц дают грузоподъемность с силой удара
жизнь ограничивает здоровье. выносливость = здоровье + ярость(+ярость при уроне герою("второй шанс"),противникам("кураж") или увидев-услышав урон по союзникам от противников ) здоровьё=(число состояния конечности(если в конечности 0 = конечности нет, урон влияет на всю оставшуюся часть от места урона до конца конечности) +литры крови) - интоксикация(делитель утоления голода и жажды) урон в руки = -число и скорость действий ими. урон в ноги = -скорость,грузоподъёмность, возможность прыжков и типы передвижений(до ползанья). здоровьё+=самовосстановление здоровья до первого большего целого четного числа(разово-чтоб не +здоровье уроном) /пищей-питьём(тоже до первого целого четного числа,одноразово,но значительно дольше от времени на поглощение, переваривание и восполнение) /аптечкой /аптечкой и помощью союзников(вправление суставов/перевозка) /больницей(если успеют донести союзники),чем больше урон,тем больше времени на лечение и больше нужно ресурсов нужных типов()
огнестрел имеет(кроме параметров как для предмета) /тип снарядов /режимы стрельбы /скорость стрельбы(скорость снарядов+задержка выстрела) /перегрев(от типа и времени стрельбы типом снарядов) /разброс(стартовый(число на Н-дальности)+перегрев+сила и направление ветра с плотностью воздуха(от погоды=дождь/снег/ливень/вьюга)) /предельная дальность стрельбы /эффективная дальность стрельбы(наибольшее значение урона в точке полета снаряда) /траектория полёта(кривая в инспекторе) /изменение скорости полёта снаряда в траектории((начальная скорость/дальность от эффективной до предельной )-плотность воздуха*направление и сила ветра) /результат при попадании от типа снаряда(и типа с текущим состоянием цели)(прострел/взрыв/разъёдание/пожар)
вместимость инвентаря = грузоподъемность - (вес одежды с карманами ( + вес сумки) + вес предмета в них) + вес предметов в руках(нельзя поместить предмет размером больше, чем карман/сумка; а если предмет у героя в руках(от размера и/или - веса в одной-двух) он не может взять(в руки/инвентарь) без бросания(на пол/в инвентарь) предмета(ов) в руке(ах). грузоподъемность влияет на выносливость, а выносливость ограничена здоровьем. что скажите)
привет! поставил лайк, пишу коммент в поддержку) на самом деле, хотел поворчать, мол, это всё слишком простые вещи, и от крутых ребят хочется больше технического хардкора, а не вот эти вот штуки, где в десятитысячный раз объясняется база. но тут куча начинающих, которым это заходит, и, наверно, с точки зрения ведения блога это выгоднее.. только не скатись, пожалуйста, в ролики с рассказами про то, как переменные заводить :) в любом случае, спасибо за видос, ждём новых (хардкорных) выпусков)
Вариант с методом, который имеет приставку Try не совсем верный, так как не декомпозирован до конца. Такой метод довольно сложно тестировать, так как он перегружен логикой. Вот один из вариантов для декомпозиции. Надо разделить методы на: - те, что вычисляют что-то и возвращают результат, но при этом не изменяют состояние объекта - и на те, которые ничего не возвращают и только изменяют состояние объекта К слову, ты указал этот вариант в ролике, но не объяснил между ними разницу с точки зрения архитектуры и отдал предпочтение первому варианту без обоснования.
С точки зрения тестирования второй вариант удобнее, да, согласен что надо было дополнительно это проговорить. Первый вариант мне по душе с точки зрения удобства использования) Спасибо за грамотную критику!
Почему бы не сделать свойства монет и максимального количества монет сразу uint? При нормальных условиях у нас в принципе не должная быть возможность сделать отрицательное количество первого или второго. Только если мы будем учитывать банкротство, это не подойдёт
1. Добавлять во все места исключения - это не очень хорошо 2. В unity ничего не писал, но разве нельзя сделать, чтобы Maze возвращал константный объект с ячейками, тогда и удалять ничего нельзя будет
предмет имеет ИМЯ(только для чтения) ОПИСАНИЕ(из вопросов проводитЭлектр?/магнитится?/загорится?/взорвётся?/списокСостоянийИзначально(Жидкость/газ/твердое/плазму не предлагать)?) ТИП РАЗМЕР(может быть изменён в ущерб предмету, если не составной ) ВЕС(уменьшается при ущербе) ПРОЧНОСТЬ(и текущее состояние с уточнением можетбытьпочинино?=если изначально не поставлена галочка, то при Н-ущербе она будет включена(пища гниет сама)) жидкость набирается ёмкостью(прочностью от типа материала и конструкции), при переливании часть теряется, как при очистке/кипячении(если вода)
по поводу кодстайла, когда переменные переносятся ниже функций. А зачем так делать? Несколько раз уже в разных проектах занимался отладкой чужого кода. Натыкаюсь на неизвестную переменную, лезу в шапку, не нахожу ее там. Лезу в родителей по наследованию, там бывает по 5-6 этажей (ради не пойми чего), нигде н нахожу. И только потом потеряв кучу времени нахожу в начальном классе где то в нижней четверти, куда и не полез бы никогда. Смысл?
Никто не переносит переменные ниже функций. Сначала поля, потом конструктор, потом свойства, потом методы. Свойства ставят ближе к методам, потому что они по своей сути больше к функциональным членам относятся. А чтобы не надо было руками искать поля можно же просто сразу к ним переходить используя возможности вижуалки и райдера
народ помогите пожалуйста. Есть код и в нем подчеркивается Console.ReadLine() int a, b, c; a = int.Parse(Console.ReadLine()); b = int.Parse(Console.ReadLine()); c = a + b; Console.WriteLine(c); решение предлагает vs, преобразовать в операторы верхнего уровня. Как это решить? Это происходит в .Net Cor
Если хочешь отдельно проверять, добавилось или нет - пожалуйста. А ещё, например, можно при переполнении кошелька возвращать избыток в виде числа чтобы положить обратно на тот счёт, с которого снял.
Что ж поржал с примера с про кошелек. Обычно пишется типа public void AddCoins(int coins){ Coins += coins; if(Coins > MaxCoins){ Coins = MaxCoins; } } И какой смысл в методе TryGetCoins ?
Поздравляю, ты дошел до темы бизнес логика с инвариантами. Зачем на самом деле нужна инкапсуляция? Чтобы ты контролировал то, в каких состояниях данные могут оказаться. Потому что если ты можешь с достаточной точностью знать в каком состоянии могут оказаться данные -- меньше будет багов, проще контролировать систему, о плюсах можно говорить долго, и иногда это жизненная необходимость. Зачем TryAddCoins или проверка на то есть ли в кошельке место? Истинная причина -- так устроена система. Если в твоей игре к примеру в тз написано "если игрок подбирает деньги больше максимума то деньги начисляются до максимума, баланс не может быть больше максимума" то в AddCoins будет то что ты написал. А так твоя версия достаточно конченная, пушо если в кошельке максимум то при отсутствии TryAddCoins с возвращаемой булкой или проверкой на наличие места игрок подберет деньги но игрок потеряет деньги, потому что часть вылезет за лимит, збс из тебя геймдиз. В чем ещё преимущество? Wallet это на самом деле часть объектной модели приложения. Мы можем сделать класс Coin, который когда его подбирают он начисляет в кошелек бабки предположим 50, можем сделать класс Diamond который начисляет 100 в Wallet при подборе. Вот тебе простой пример композиции. Может быть ситуация что там будет сундук, который при подборе предлагает глянуть рекламу, а потом при успехе начисляет в кошелек 150, вот пример чуть более сложной композиции. А что будет если есть лимит бабла и мы предлагаем рекламу? Тут если гнуть свою линию то нужно чекать лимит и говорить что рекламу смотреть нет необходимости пушо и так кошелек полон, предлагать потратить деньги
⚡⚡⚡ Полезные ссылки ⚡⚡⚡
🔎 t.me/yakovlev_gamedev - ссылка на мой telegram канал (тут инфу про запись на курс можно получиться быстрее всех)
🔎 boosty.to/yakovlevgamedev - ссылка на бусти (тут можно поддержать канал, выход новых видео и даже получить эксклюзивные ништяки)
🔎 ua-cam.com/channels/C-hfECZdghe_QNAJzztHEg.html - ссылка на канал моего младшего брата (подпишись если не сложно)
Понравилось определение инкапсуляции, что это защита состояния объекта, а не как много где написано "сокрытие полей".
Самое подробное объяснение инкапсуляции на примерах что я видел!!!
Вариант с Ttry действительно классный! И вообще очень годная тема. Спасибо!
Методы, которые начинаются на Try - не очень практика, так делать не стоит
Отличное видео с подробным объяснением важной темы
Хорошее видео,наконец понял зачем нужна инкапсуляция,теперь буду переделывать весь свой код)
Хароооош, видео то что надо. Вроде и знал что-то про инкопсуляцию но вот некоторые моментики подчерпнул. Например "не надо выдавать наружу что-то с публичным интерфейсом" - звучит хорошо. Держи лайк)
круто, спасибо, много нового узнал
выносливость -=
угол подъёма(подниматься медленнее и тяжелее, особенно при 90: вверх по скале-веревке)
+(скорость передвижения(от направления и положения тела = ползать со скоростью бега не получится, а на карачках и задом на перед = наиболее затратное и медленное)*груз)
+(температура окружающей среды-температура тела)
+ боль(множитель трат выносливости )
или число действий*0.2(чем больше действий за н-времени,тем больше тратится на каждое последующее)
выносливость += само до 0.7 здоровья за Н-времени оперевшись на стенку
/после бега(питьё, ограниченное скоростью питья и переваривания с размером желудка, при равном-большем рвота, а при равном и беге/драке = рвота)
/от усталости(сном в Н-часов, в зависимости от состояния нпс, если он примет бодрящее вещество, то усталость=0, но через Н-времени интоксикация повлияет(после приема +интоксикация на все время влияния вещества, уменьшая здоровье, голод,жажду и положительное воздействие питья/пищи))
грузоподъемность = рост + физ.кондиция(мышцы/жир)(только от мышц +грузоподъемность )
рост даёт потенциальную скорость бега от размаха ног.
скорость +физ.кондиции = стартовая + типы питания + Н-действий за Н-время(питание поддерживает текущие)
жир даёт -голода/размер желудка и -выносливости с +сопротивляемостьХолоду
мышц дают грузоподъемность с силой удара
жизнь ограничивает здоровье.
выносливость =
здоровье
+ ярость(+ярость при уроне герою("второй шанс"),противникам("кураж") или увидев-услышав урон по союзникам от противников )
здоровьё=(число состояния конечности(если в конечности 0 = конечности нет, урон влияет на всю оставшуюся часть от места урона до конца конечности)
+литры крови) - интоксикация(делитель утоления голода и жажды)
урон в руки = -число и скорость действий ими.
урон в ноги = -скорость,грузоподъёмность, возможность прыжков и типы передвижений(до ползанья).
здоровьё+=самовосстановление здоровья до первого большего целого четного числа(разово-чтоб не +здоровье уроном)
/пищей-питьём(тоже до первого целого четного числа,одноразово,но значительно дольше от времени на поглощение, переваривание и восполнение)
/аптечкой
/аптечкой и помощью союзников(вправление суставов/перевозка)
/больницей(если успеют донести союзники),чем больше урон,тем больше времени на лечение и больше нужно ресурсов нужных типов()
огнестрел имеет(кроме параметров как для предмета)
/тип снарядов
/режимы стрельбы
/скорость стрельбы(скорость снарядов+задержка выстрела)
/перегрев(от типа и времени стрельбы типом снарядов)
/разброс(стартовый(число на Н-дальности)+перегрев+сила и направление ветра с плотностью воздуха(от погоды=дождь/снег/ливень/вьюга))
/предельная дальность стрельбы
/эффективная дальность стрельбы(наибольшее значение урона в точке полета снаряда)
/траектория полёта(кривая в инспекторе)
/изменение скорости полёта снаряда в траектории((начальная скорость/дальность от эффективной до предельной )-плотность воздуха*направление и сила ветра)
/результат при попадании от типа снаряда(и типа с текущим состоянием цели)(прострел/взрыв/разъёдание/пожар)
Cool, thanks. I always forget about it
вместимость инвентаря = грузоподъемность - (вес одежды с карманами ( + вес сумки) + вес предмета в них) + вес предметов в руках(нельзя поместить предмет размером больше, чем карман/сумка; а если предмет у героя в руках(от размера и/или - веса в одной-двух) он не может взять(в руки/инвентарь) без бросания(на пол/в инвентарь) предмета(ов) в руке(ах). грузоподъемность влияет на выносливость, а выносливость ограничена здоровьем. что скажите)
привет!
поставил лайк, пишу коммент в поддержку)
на самом деле, хотел поворчать, мол, это всё слишком простые вещи, и от крутых ребят хочется больше технического хардкора, а не вот эти вот штуки, где в десятитысячный раз объясняется база. но тут куча начинающих, которым это заходит, и, наверно, с точки зрения ведения блога это выгоднее.. только не скатись, пожалуйста, в ролики с рассказами про то, как переменные заводить :)
в любом случае, спасибо за видос, ждём новых (хардкорных) выпусков)
Вариант с методом, который имеет приставку Try не совсем верный, так как не декомпозирован до конца. Такой метод довольно сложно тестировать, так как он перегружен логикой.
Вот один из вариантов для декомпозиции. Надо разделить методы на:
- те, что вычисляют что-то и возвращают результат, но при этом не изменяют состояние объекта
- и на те, которые ничего не возвращают и только изменяют состояние объекта
К слову, ты указал этот вариант в ролике, но не объяснил между ними разницу с точки зрения архитектуры и отдал предпочтение первому варианту без обоснования.
С точки зрения тестирования второй вариант удобнее, да, согласен что надо было дополнительно это проговорить. Первый вариант мне по душе с точки зрения удобства использования) Спасибо за грамотную критику!
Почему бы не сделать свойства монет и максимального количества монет сразу uint? При нормальных условиях у нас в принципе не должная быть возможность сделать отрицательное количество первого или второго. Только если мы будем учитывать банкротство, это не подойдёт
1. Добавлять во все места исключения - это не очень хорошо
2. В unity ничего не писал, но разве нельзя сделать, чтобы Maze возвращал константный объект с ячейками, тогда и удалять ничего нельзя будет
предмет имеет
ИМЯ(только для чтения)
ОПИСАНИЕ(из вопросов проводитЭлектр?/магнитится?/загорится?/взорвётся?/списокСостоянийИзначально(Жидкость/газ/твердое/плазму не предлагать)?)
ТИП
РАЗМЕР(может быть изменён в ущерб предмету, если не составной )
ВЕС(уменьшается при ущербе)
ПРОЧНОСТЬ(и текущее состояние с уточнением можетбытьпочинино?=если изначально не поставлена галочка, то при Н-ущербе она будет включена(пища гниет сама))
жидкость набирается ёмкостью(прочностью от типа материала и конструкции), при переливании часть теряется, как при очистке/кипячении(если вода)
2к за один день. Вот это актив
по поводу кодстайла, когда переменные переносятся ниже функций.
А зачем так делать? Несколько раз уже в разных проектах занимался отладкой чужого кода. Натыкаюсь на неизвестную переменную, лезу в шапку, не нахожу ее там. Лезу в родителей по наследованию, там бывает по 5-6 этажей (ради не пойми чего), нигде н нахожу. И только потом потеряв кучу времени нахожу в начальном классе где то в нижней четверти, куда и не полез бы никогда. Смысл?
Никто не переносит переменные ниже функций. Сначала поля, потом конструктор, потом свойства, потом методы. Свойства ставят ближе к методам, потому что они по своей сути больше к функциональным членам относятся. А чтобы не надо было руками искать поля можно же просто сразу к ним переходить используя возможности вижуалки и райдера
Я использую Rider. Там не надо долго искать, один клик по переменной. Как в остальных IDE, не могу сказать.
народ помогите пожалуйста. Есть код и в нем подчеркивается Console.ReadLine()
int a, b, c;
a = int.Parse(Console.ReadLine());
b = int.Parse(Console.ReadLine());
c = a + b;
Console.WriteLine(c);
решение предлагает vs, преобразовать в операторы верхнего уровня. Как это решить? Это происходит в .Net Cor
А можно логику метода add() написать в set в поле? И нужно ли делать именно метод для подобного или это зависит от удобства?
Если хочешь отдельно проверять, добавилось или нет - пожалуйста. А ещё, например, можно при переполнении кошелька возвращать избыток в виде числа чтобы положить обратно на тот счёт, с которого снял.
Что ж поржал с примера с про кошелек. Обычно пишется типа
public void AddCoins(int coins){
Coins += coins;
if(Coins > MaxCoins){
Coins = MaxCoins;
}
}
И какой смысл в методе TryGetCoins ?
Поздравляю, ты дошел до темы бизнес логика с инвариантами. Зачем на самом деле нужна инкапсуляция? Чтобы ты контролировал то, в каких состояниях данные могут оказаться. Потому что если ты можешь с достаточной точностью знать в каком состоянии могут оказаться данные -- меньше будет багов, проще контролировать систему, о плюсах можно говорить долго, и иногда это жизненная необходимость. Зачем TryAddCoins или проверка на то есть ли в кошельке место? Истинная причина -- так устроена система. Если в твоей игре к примеру в тз написано "если игрок подбирает деньги больше максимума то деньги начисляются до максимума, баланс не может быть больше максимума" то в AddCoins будет то что ты написал. А так твоя версия достаточно конченная, пушо если в кошельке максимум то при отсутствии TryAddCoins с возвращаемой булкой или проверкой на наличие места игрок подберет деньги но игрок потеряет деньги, потому что часть вылезет за лимит, збс из тебя геймдиз. В чем ещё преимущество? Wallet это на самом деле часть объектной модели приложения. Мы можем сделать класс Coin, который когда его подбирают он начисляет в кошелек бабки предположим 50, можем сделать класс Diamond который начисляет 100 в Wallet при подборе. Вот тебе простой пример композиции. Может быть ситуация что там будет сундук, который при подборе предлагает глянуть рекламу, а потом при успехе начисляет в кошелек 150, вот пример чуть более сложной композиции. А что будет если есть лимит бабла и мы предлагаем рекламу? Тут если гнуть свою линию то нужно чекать лимит и говорить что рекламу смотреть нет необходимости пушо и так кошелек полон, предлагать потратить деньги
простите, наверно, надоел!?)