А что если эта система галлюцинирует? Скажем один агент нагалюцинировал в аналитике(перепутал цифры), потом эта маленькая неточность по цепочке превращается в снежный ком и в итоге получаем неверное стратегическое решение. Без системы которая на 100% исключит эффект галлюцинаций этим пользоваться опасно.
PS: опять же если верификатора на верификатора начнем добавлять, то снежным комом вырастет цена любого решения.
Я вам наверно уже надоел, но позвольте ещё позанудствую: в примере с прямоугольником и квадратом все от требований зависит. Ваш пример искусственный. Если мы смотреть на него в общем смысле, то поведение SetB, SetA и GetS(), скрыты и могут быть какими угодно, гарантий что сделав SetB он не посинеет и не взорвется нет никаких. Так же GetS() никак не зависит от реализации вызовов SetA, SetB иначе мы раскрываем слишком много знаний, важно что у него есть GetS и мы можем его вызвать. В любом случае если в конкретной модели квадрат не может быть прямоугольником то и не нужно его таковым делать. Так же не вижу ничего плохого в "ничего не делать" для воина, так как во-первых это ничего не ломает, во-вторых мы всё-таки что-то сделаем, например кинем Событие и возможно покажем игроку уведомление.
Прошу прощения цикл статей ещё не читал, но все же спрошу, а чем плох вариант когда Игрок.Взять(Оружие) просто ничего не делает(если он Воин и оружие Посох-dynamic cast, либо добавляем ВзятьОружие через паттерн Визитор)?
Если вдруг на пол пути захочется условно из РПГ сделать FPS, то да тут ООП пасс :) да тут и нет простого пути. Любая модульность будь то ООП либо просто разбиение кода по си файлам уже вносят структуру, а любую структуру ломать тяжело, кроме конечно самой базовой(гейм луп, графика, физика, звук, управление).
В тех фреймворках в которых я работал, поддержка языков уже встроена или добавляется с пол пинка. Ну например WPF, или старый добрый WinForms. Все тексты уже лежат в ресурсах на нужных формах в 90% . Нужен новый язык, создаётся новый условно пакет форм и там можно рисовать новый язык и даже внешний вид. Поэтому я и поинтересовался на чем вы так споткнулись?
Если я правильно помню этот принцип, то грубо говоря он выставляет нам только одно требование: использование любого наследника в качестве базового класса, не должно ломать программу, то есть неважно какого наследника мы подсунем, поведение кода не будет сломано. Если алгоритму все равно, маг это или воин, то и принцип не нарушается. Например, рендеру все равно кто это, главное чтобы у него например был метод draw, например. Там где есть разница, там и принимать нужно либо мага либо воина.
Касательно цен, то можно и не прокидывать в каждую функцию новый параметр, как вариант можно DI контейнеры использовать, в корпоративе это по-моему уже мастхэв в проектах.
А на чем гуй писали если не секрет, я просто не припомню когда мне последний раз требовалось тексты в коде хранить. Обычно это либо XML, HTML либо встроенный ещё какой либо формат независимый от кода, поддерживаемый фреймворком.
Ну вот не знаю, у нас в корпоративном секторе все хорошо относительно. Примерно понятна архитектура, понятно какие будут бизнес энтити и бизнес правила. Опять же DDD подход сильно упрощает реакцию на неожиданные требования. Опять же хорошее знание паттерны проектирования, многие проблемы с ООП снимает ещё на старте. Поэтому для меня начало статьи где описывалась объектная модель игры и проблемы подхода показались немного детскими.
Как раз в этом случае данный подход и хорош, надо такую же логику но чуть изменённую, создаётся класс AttackWithBitDifferentLogicUseCase(например AttackByAxeEmpoweredWithMagicUseCase и тд), наследуется от базового. Паттерн Шаблонный Метод можно так же использовать для изменения поведения в нужную сторону. Либо уже использовать Стратегию, если явно прослеживается необходимость комбинировать какие-то варианты.
А в геймдеве используют подход из DDD, когда бизнес логика описывается отдельным классом-хэндлером? Грубо говоря, это могло бы выглядеть как то так, например юнит А атакует юнита Б, есть класс AttackUseCase(unit a, unit b, HitParameters hparams).Handle()? Тогда не возникает проблем куда запихать логику атаки. Разные виды атак разные классы (возможно наследники от базовой атаки). Или ECS про это и есть?
на нем не должно быть такого низкокачественного шлака не зависимо от... Потому что так или иначе он попадает в новостные ленты телефонов где-то индексируясь, а мы тратим на это время.
запускалось одинаково везде (даже на машине тёти Зины);
Я уж было обрадовался и подумал расскажут как можно любое windows GUI приложение в докер запаковать и тете Зине отправить в виде исполняемого файла с автоматически разворачивающимся контейнером при старте.
А тут элементарная инструкция, которая выражается чатгпт за 10 секунд на запрос "как запустить хелло Ворд на питоне в докер" и реклама какого-то курса. Хабр уже не торт :(
Понятнее не стало. Но будем ждать следующую статью: как я построил успешный бизнес с командой агентов.
Ничего не понятно но очень интересно
А что если эта система галлюцинирует? Скажем один агент нагалюцинировал в аналитике(перепутал цифры), потом эта маленькая неточность по цепочке превращается в снежный ком и в итоге получаем неверное стратегическое решение. Без системы которая на 100% исключит эффект галлюцинаций этим пользоваться опасно.
PS: опять же если верификатора на верификатора начнем добавлять, то снежным комом вырастет цена любого решения.
Я вам наверно уже надоел, но позвольте ещё позанудствую: в примере с прямоугольником и квадратом все от требований зависит. Ваш пример искусственный. Если мы смотреть на него в общем смысле, то поведение SetB, SetA и GetS(), скрыты и могут быть какими угодно, гарантий что сделав SetB он не посинеет и не взорвется нет никаких. Так же GetS() никак не зависит от реализации вызовов SetA, SetB иначе мы раскрываем слишком много знаний, важно что у него есть GetS и мы можем его вызвать. В любом случае если в конкретной модели квадрат не может быть прямоугольником то и не нужно его таковым делать. Так же не вижу ничего плохого в "ничего не делать" для воина, так как во-первых это ничего не ломает, во-вторых мы всё-таки что-то сделаем, например кинем Событие и возможно покажем игроку уведомление.
Прошу прощения цикл статей ещё не читал, но все же спрошу, а чем плох вариант когда Игрок.Взять(Оружие) просто ничего не делает(если он Воин и оружие Посох-dynamic cast, либо добавляем ВзятьОружие через паттерн Визитор)?
Если вдруг на пол пути захочется условно из РПГ сделать FPS, то да тут ООП пасс :) да тут и нет простого пути. Любая модульность будь то ООП либо просто разбиение кода по си файлам уже вносят структуру, а любую структуру ломать тяжело, кроме конечно самой базовой(гейм луп, графика, физика, звук, управление).
В тех фреймворках в которых я работал, поддержка языков уже встроена или добавляется с пол пинка. Ну например WPF, или старый добрый WinForms. Все тексты уже лежат в ресурсах на нужных формах в 90% . Нужен новый язык, создаётся новый условно пакет форм и там можно рисовать новый язык и даже внешний вид. Поэтому я и поинтересовался на чем вы так споткнулись?
Если я правильно помню этот принцип, то грубо говоря он выставляет нам только одно требование: использование любого наследника в качестве базового класса, не должно ломать программу, то есть неважно какого наследника мы подсунем, поведение кода не будет сломано. Если алгоритму все равно, маг это или воин, то и принцип не нарушается. Например, рендеру все равно кто это, главное чтобы у него например был метод draw, например. Там где есть разница, там и принимать нужно либо мага либо воина.
Касательно цен, то можно и не прокидывать в каждую функцию новый параметр, как вариант можно DI контейнеры использовать, в корпоративе это по-моему уже мастхэв в проектах.
А можно тут подробнее, чем принцип Лисков плох? И зачем наследовать квадрат от прямоугольника? )
А на чем гуй писали если не секрет, я просто не припомню когда мне последний раз требовалось тексты в коде хранить. Обычно это либо XML, HTML либо встроенный ещё какой либо формат независимый от кода, поддерживаемый фреймворком.
А что у вас тексты прям захардкожены были? А цены тоже?
Ну вот не знаю, у нас в корпоративном секторе все хорошо относительно. Примерно понятна архитектура, понятно какие будут бизнес энтити и бизнес правила. Опять же DDD подход сильно упрощает реакцию на неожиданные требования. Опять же хорошее знание паттерны проектирования, многие проблемы с ООП снимает ещё на старте. Поэтому для меня начало статьи где описывалась объектная модель игры и проблемы подхода показались немного детскими.
И что, в каждой новой игре вот так, ничего неясно? никаких паттернов не прослеживается?
Как раз в этом случае данный подход и хорош, надо такую же логику но чуть изменённую, создаётся класс AttackWithBitDifferentLogicUseCase(например AttackByAxeEmpoweredWithMagicUseCase и тд), наследуется от базового. Паттерн Шаблонный Метод можно так же использовать для изменения поведения в нужную сторону. Либо уже использовать Стратегию, если явно прослеживается необходимость комбинировать какие-то варианты.
А в геймдеве используют подход из DDD, когда бизнес логика описывается отдельным классом-хэндлером? Грубо говоря, это могло бы выглядеть как то так, например юнит А атакует юнита Б, есть класс AttackUseCase(unit a, unit b, HitParameters hparams).Handle()? Тогда не возникает проблем куда запихать логику атаки. Разные виды атак разные классы (возможно наследники от базовой атаки). Или ECS про это и есть?
Критиковать задним числом оно всегда проще.
на нем не должно быть такого низкокачественного шлака не зависимо от... Потому что так или иначе он попадает в новостные ленты телефонов где-то индексируясь, а мы тратим на это время.
Я уж было обрадовался и подумал расскажут как можно любое windows GUI приложение в докер запаковать и тете Зине отправить в виде исполняемого файла с автоматически разворачивающимся контейнером при старте.
А тут элементарная инструкция, которая выражается чатгпт за 10 секунд на запрос "как запустить хелло Ворд на питоне в докер" и реклама какого-то курса. Хабр уже не торт :(
А чем плох широко распространенный YAML?