VZ
Size: a a a
2021 January 13
ET
но в Tensor<T> и близко нет того, что он хочет для матриц. там весьма лапидарное API.
2021 January 14
t
Леха (Felix)
Не совсем понимаю как её здесь применить(
Абстрактньій метод взаимодействие() для каждого дочернего класса унаследованого от базового класса «предмет»?
t
Леха (Felix)
Появился вопрос по архитектуре. Посыл: я хочу сделать обобщенную систему предметов. Допустим чтобы игрок мог поднять любой предмет будь то броня или поушн и по разному с ним взаимодействовать. Также такие предметы могут продаваться во внутриигровом магазине и по разному в нём отображаться и тд. Но опыта не хватает сделать что-то грамотно вот и хочу посоветоваться. Первое что в голову влезло, это сделать божественный класс со всеми возможными предметами, и работать по enum и аля если в енаме указано что это броня то работать с полем equip, если в енаме указано что это зелье то работать с полем potionData и тд. Насколько такое решение какашечное и как бы вы поступили на моём месте?
Тьі вначале четко для себя определи, какие свойства должньв бьіть у предмета м чем отличаются они для магаза и игрока (поведение и/или место и куда надеть/на какой полке магаза разместить
Dv
Леха (Felix)
Появился вопрос по архитектуре. Посыл: я хочу сделать обобщенную систему предметов. Допустим чтобы игрок мог поднять любой предмет будь то броня или поушн и по разному с ним взаимодействовать. Также такие предметы могут продаваться во внутриигровом магазине и по разному в нём отображаться и тд. Но опыта не хватает сделать что-то грамотно вот и хочу посоветоваться. Первое что в голову влезло, это сделать божественный класс со всеми возможными предметами, и работать по enum и аля если в енаме указано что это броня то работать с полем equip, если в енаме указано что это зелье то работать с полем potionData и тд. Насколько такое решение какашечное и как бы вы поступили на моём месте?
Читай про ECS, в современно геймдеве часто именно такую архитектуру используют.
IB
мхм, есть класс, с именем А, у него есть свойство B. Есть класс C со свойством A A {get}
В классе C надо взять nameof(A.B), но наличие свойства с таким же именем делает это невозможным. Нет ли возможности обойти это препятствие?
В классе C надо взять nameof(A.B), но наличие свойства с таким же именем делает это невозможным. Нет ли возможности обойти это препятствие?
IB
*обошел инициализацией в конструкторе. при field inizialization это невозможно.
AT
мхм, есть класс, с именем А, у него есть свойство B. Есть класс C со свойством A A {get}
В классе C надо взять nameof(A.B), но наличие свойства с таким же именем делает это невозможным. Нет ли возможности обойти это препятствие?
В классе C надо взять nameof(A.B), но наличие свойства с таким же именем делает это невозможным. Нет ли возможности обойти это препятствие?
nameof(ns.A.B)?AT
nameof(ns.A.B)?Можно ещё сделать псевдоним для пространства имён, в котором лежит А, либо для самого типа А, и тогда запись в nameof будет короче
AT
жалко что
using Alias = Orig нельзя сделать в произвольном местеIB
nameof(ns.A.B)?да. очевидное и рабочее решение. спасибо.
Dv
мхм, есть класс, с именем А, у него есть свойство B. Есть класс C со свойством A A {get}
В классе C надо взять nameof(A.B), но наличие свойства с таким же именем делает это невозможным. Нет ли возможности обойти это препятствие?
В классе C надо взять nameof(A.B), но наличие свойства с таким же именем делает это невозможным. Нет ли возможности обойти это препятствие?
FQN пиши, да
Dv
Если и FQN неоднозначный, тогда есть мего решение
Dv
nameof(global::FQN.A.B)AT
nameof(global::FQN.A.B)обычно эта строка выдаёт кодогенерацию