Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Интересно, Эдуардо понимает, что он просто использует две хороших методики в проекте? MVC и Microservices.
В любом большом проекте используется набор парадигм, т.к. в любом проекте большой круг задач. Фронт энд, бэк энд, тулзы и т.д. А написание игры это вообще все вместе. Начиная от рендера и заканчивая чатиком в тиме. Конечно там будет мультипарадигменное решение.
Я это к чему. Что AMVCC попахивает ЧСВ )
В любом большом проекте используется набор парадигм, т.к. в любом проекте большой круг задач. Фронт энд, бэк энд, тулзы и т.д. А написание игры это вообще все вместе. Начиная от рендера и заканчивая чатиком в тиме. Конечно там будет мультипарадигменное решение.
Я это к чему. Что AMVCC попахивает ЧСВ )
Мне показалась интересным организация MVC на уровне объектов в дереве EC. Я с такой практикой никогда раньше не встречался, поэтому решил поделиться с Хабром. Да и от микросервисов тут разве что эвент-шина.
Да я и не говорил, что статья бесполезная, если вы так подумали. Я про «еще один стандарт» и ЧСВ )
А микросервисы в данном случае это компоненты. Т.е. сущность выполняющая узкую специализацию.
А микросервисы в данном случае это компоненты. Т.е. сущность выполняющая узкую специализацию.
Можете указать на место, где упоминается, что AMVCC — стандарт? Скорее всего, я что-то неправильно перевёл.
Я бы назвал компонент микросервисом. Всё-таки компонент — это компонент. А микросервис я себе представляю, как изолированную программу с web- и/или rpc- интерфейсом. Игра же — монолит. Поправьте, если я не прав, мне роднее и привычнее веб.
Я бы назвал компонент микросервисом. Всё-таки компонент — это компонент. А микросервис я себе представляю, как изолированную программу с web- и/или rpc- интерфейсом. Игра же — монолит. Поправьте, если я не прав, мне роднее и привычнее веб.
Я плохо выразился. «еще один стандарт» — это ироничная картинка, применительно к «еще одному» шаблону проектирования. )
Микросервисы — в общем плане (есть другой термин более абстрактный, из головы сейчас вылетело) это сущность выполняющая узкую работу. В вебе вы будете это применять как микросервисы, при написании SDK вы будете делать легковесные библиотеки, при написании игры вы будете выносить околоигровые вещи в компоненты, например чат. Это же всего лишь одна из парадигм. Микросервисы очень хорошо переиспользуются и на них удобно строить программы-агрегаторы.
Если говорить конкретно про игры, то тут можно книгу написать, где там подходы микросервисов-компонентов на самых разных уровнях абстракции )
Вот скелетную анимацию можно сделать как компонент (у объекта есть Иерархия костей, которая может использоваться как рендером так и физикой). А можно как жестко связанную с рендером систему. Т.е. меш и кость знают друг о друге многое )
Да и, честно говоря, мне кажется Эдуардо наслаивает свое виденье игрового движка на уже готовый.
При проектировании двигла обычно закладываются сценарии использования. Ну и как правило попытка охватить всё-всё-всё. Вот только способы решения одних и тех же задач, в разных движках разные. Ну слава богу сейчас более менее все сошлись, что игровой объект, рендер и физический объект это три большие разницы и их можно и нужно считать раздельно. Давным давно игровой объект содержал что то типа AmmoCount, Parent(в контексте SceneGraph) и Velocity.
Микросервисы — в общем плане (есть другой термин более абстрактный, из головы сейчас вылетело) это сущность выполняющая узкую работу. В вебе вы будете это применять как микросервисы, при написании SDK вы будете делать легковесные библиотеки, при написании игры вы будете выносить околоигровые вещи в компоненты, например чат. Это же всего лишь одна из парадигм. Микросервисы очень хорошо переиспользуются и на них удобно строить программы-агрегаторы.
Если говорить конкретно про игры, то тут можно книгу написать, где там подходы микросервисов-компонентов на самых разных уровнях абстракции )
Вот скелетную анимацию можно сделать как компонент (у объекта есть Иерархия костей, которая может использоваться как рендером так и физикой). А можно как жестко связанную с рендером систему. Т.е. меш и кость знают друг о друге многое )
Да и, честно говоря, мне кажется Эдуардо наслаивает свое виденье игрового движка на уже готовый.
При проектировании двигла обычно закладываются сценарии использования. Ну и как правило попытка охватить всё-всё-всё. Вот только способы решения одних и тех же задач, в разных движках разные. Ну слава богу сейчас более менее все сошлись, что игровой объект, рендер и физический объект это три большие разницы и их можно и нужно считать раздельно. Давным давно игровой объект содержал что то типа AmmoCount, Parent(в контексте SceneGraph) и Velocity.
Я плохо выразился. «еще один стандарт» — это ироничная картинка, применительно к «еще одному» шаблону проектирования. )
Почему-то я волнуюсь после публикации и не могу с первого раза правильно воспринять иронию)
Микросервисы — в общем плане (есть другой термин более абстрактный, из головы сейчас вылетело) это сущность выполняющая узкую работу.
Будет круто, если вы вспомните и поделитесь термином, потому что теперь интересно, как это называется.
Вспомню — обязательно отпишусь (в голове крутятся такие вещи как «декомпозиция» и «изолированные компоненты»).
Но надо понимать, что каждая область обрастает своими терминами, описывающими одну и ту же сущность. Ну чтобы холивара не было ) В радиоэлектронике это будет что то свое. В кулинарии та же «петрушка». Вот даже на уровне OS, в юникс-системах одной из фундаментальных идей были небольшие тулзы, общающиеся через разные каналы связи, от stdout до pipe. Вот ping, например, как назвать? Измерительная тулза или микросервис (если вкладывать тот смысл, что я описал). В мире скоростных вычислений Intel® Math Kernel Library библиотека или «микросервис» на уровне кода. Вот к какой-нибудь SDK приписать такие свойства уже не получится.
Но надо понимать, что каждая область обрастает своими терминами, описывающими одну и ту же сущность. Ну чтобы холивара не было ) В радиоэлектронике это будет что то свое. В кулинарии та же «петрушка». Вот даже на уровне OS, в юникс-системах одной из фундаментальных идей были небольшие тулзы, общающиеся через разные каналы связи, от stdout до pipe. Вот ping, например, как назвать? Измерительная тулза или микросервис (если вкладывать тот смысл, что я описал). В мире скоростных вычислений Intel® Math Kernel Library библиотека или «микросервис» на уровне кода. Вот к какой-нибудь SDK приписать такие свойства уже не получится.
На мой взгляд, статья пестрит вредными советами:
— Дополнительное наследование от BounceElement не есть хорошо, да и получение ссылок таким образом такие же минусы влечет за собой как и Service Locator.
— Зачем держать в сцене классы логики как MonoBehaviour, если можно создать их нормально.
— При росте проекта либо увеличится количество классов контроллера, и появится много связей многие ко многим, так как о всех знают все, либо контроллеры разрастутся и придется перечитывать главу про SOLID.
Для примера того как можно писать, конечно подходит.
— Дополнительное наследование от BounceElement не есть хорошо, да и получение ссылок таким образом такие же минусы влечет за собой как и Service Locator.
— Зачем держать в сцене классы логики как MonoBehaviour, если можно создать их нормально.
— При росте проекта либо увеличится количество классов контроллера, и появится много связей многие ко многим, так как о всех знают все, либо контроллеры разрастутся и придется перечитывать главу про SOLID.
Для примера того как можно писать, конечно подходит.
>Зачем держать в сцене классы логики как MonoBehaviour, если можно создать их нормально
Например, модели сделаны как MonoBehaviour для возможности изменять значения прямо в редакторе.
А контроллеры можно и не делать MonoBehaviour.
А вот то, что свойство app в BounceApplication не кэширует ссылку — это странно. Ну и много чего, что можно было бы улучшить, хотя бы — служебные классы сделать абстрактным, события в BounceNotification — не строковые, перечисления, и т.п.
Например, модели сделаны как MonoBehaviour для возможности изменять значения прямо в редакторе.
А контроллеры можно и не делать MonoBehaviour.
А вот то, что свойство app в BounceApplication не кэширует ссылку — это странно. Ну и много чего, что можно было бы улучшить, хотя бы — служебные классы сделать абстрактным, события в BounceNotification — не строковые, перечисления, и т.п.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Unity и MVC: как прокачать разработку игры