Для инди разработчика слишком попсовая игра. Ну мне так показалось. Таких тыщи в сторах. Инди разработка всегда подразумевала что-то уникальное, эксперимент, нестандартные решения в геймплее и тд.
Вот и этот текст такой же не интересный и мыльный. Ставлю что написан ИИ с рекламными целями попиарить телегу. А по теме, очевидно что ИИ можно попросить написать в любом стиле, с любым количеством ошибок и любого размера. И проблема тут скорее только в лени авторов, но думаю это исправится со временем ибо рынок.
Ребят, да сколько можно уже эти курсы свои втюхивать? Разве не из всех ещё сделали программистов? Давайте уже курсы таксистов и доставщиков еды, там спрос нынче выше. А программистов оставьте, пожалуйста, университетам и колледжам.
Начал читать, сначало уши начали вять от перечисления регалий автора по типу (прошла курсы, 100500 собесов провела и тд) а потом увидел какие-то советы в духе "спросить как у кандидату обращаться", что-то про там про одежду ещё, камеру проверить, и понял что к собеседованиям в реальных технических компаниях это не имеет похоже отношения. И в целом сплошная вода и советы как тратить время впустую вместо искать себе подходящих людей.
А что если эта система галлюцинирует? Скажем один агент нагалюцинировал в аналитике(перепутал цифры), потом эта маленькая неточность по цепочке превращается в снежный ком и в итоге получаем неверное стратегическое решение. Без системы которая на 100% исключит эффект галлюцинаций этим пользоваться опасно.
PS: опять же если верификатора на верификатора начнем добавлять, то снежным комом вырастет цена любого решения.
Я вам наверно уже надоел, но позвольте ещё позанудствую: в примере с прямоугольником и квадратом все от требований зависит. Ваш пример искусственный. Если мы смотреть на него в общем смысле, то поведение SetB, SetA и GetS(), скрыты и могут быть какими угодно, гарантий что сделав SetB он не посинеет и не взорвется нет никаких. Так же GetS() никак не зависит от реализации вызовов SetA, SetB иначе мы раскрываем слишком много знаний, важно что у него есть GetS и мы можем его вызвать. В любом случае если в конкретной модели квадрат не может быть прямоугольником то и не нужно его таковым делать. Так же не вижу ничего плохого в "ничего не делать" для воина, так как во-первых это ничего не ломает, во-вторых мы всё-таки что-то сделаем, например кинем Событие и возможно покажем игроку уведомление.
Прошу прощения цикл статей ещё не читал, но все же спрошу, а чем плох вариант когда Игрок.Взять(Оружие) просто ничего не делает(если он Воин и оружие Посох-dynamic cast, либо добавляем ВзятьОружие через паттерн Визитор)?
Если вдруг на пол пути захочется условно из РПГ сделать FPS, то да тут ООП пасс :) да тут и нет простого пути. Любая модульность будь то ООП либо просто разбиение кода по си файлам уже вносят структуру, а любую структуру ломать тяжело, кроме конечно самой базовой(гейм луп, графика, физика, звук, управление).
В тех фреймворках в которых я работал, поддержка языков уже встроена или добавляется с пол пинка. Ну например WPF, или старый добрый WinForms. Все тексты уже лежат в ресурсах на нужных формах в 90% . Нужен новый язык, создаётся новый условно пакет форм и там можно рисовать новый язык и даже внешний вид. Поэтому я и поинтересовался на чем вы так споткнулись?
Если я правильно помню этот принцип, то грубо говоря он выставляет нам только одно требование: использование любого наследника в качестве базового класса, не должно ломать программу, то есть неважно какого наследника мы подсунем, поведение кода не будет сломано. Если алгоритму все равно, маг это или воин, то и принцип не нарушается. Например, рендеру все равно кто это, главное чтобы у него например был метод draw, например. Там где есть разница, там и принимать нужно либо мага либо воина.
Касательно цен, то можно и не прокидывать в каждую функцию новый параметр, как вариант можно DI контейнеры использовать, в корпоративе это по-моему уже мастхэв в проектах.
А на чем гуй писали если не секрет, я просто не припомню когда мне последний раз требовалось тексты в коде хранить. Обычно это либо XML, HTML либо встроенный ещё какой либо формат независимый от кода, поддерживаемый фреймворком.
Ну вот не знаю, у нас в корпоративном секторе все хорошо относительно. Примерно понятна архитектура, понятно какие будут бизнес энтити и бизнес правила. Опять же DDD подход сильно упрощает реакцию на неожиданные требования. Опять же хорошее знание паттерны проектирования, многие проблемы с ООП снимает ещё на старте. Поэтому для меня начало статьи где описывалась объектная модель игры и проблемы подхода показались немного детскими.
Для инди разработчика слишком попсовая игра. Ну мне так показалось. Таких тыщи в сторах. Инди разработка всегда подразумевала что-то уникальное, эксперимент, нестандартные решения в геймплее и тд.
Так вы делаете или ты делаешь в одиночку? "Штирлиц никогда не был так близок к провалу"
Школьники легко осваивают создание игр в Роблокс. И там гораздо интереснее.
Вот и этот текст такой же не интересный и мыльный. Ставлю что написан ИИ с рекламными целями попиарить телегу. А по теме, очевидно что ИИ можно попросить написать в любом стиле, с любым количеством ошибок и любого размера. И проблема тут скорее только в лени авторов, но думаю это исправится со временем ибо рынок.
Ребят, да сколько можно уже эти курсы свои втюхивать? Разве не из всех ещё сделали программистов? Давайте уже курсы таксистов и доставщиков еды, там спрос нынче выше. А программистов оставьте, пожалуйста, университетам и колледжам.
Дочитал до телеграм канала вашего CEO или кого там и понял, очередные сказочники маркетологи.
Начал читать, сначало уши начали вять от перечисления регалий автора по типу (прошла курсы, 100500 собесов провела и тд) а потом увидел какие-то советы в духе "спросить как у кандидату обращаться", что-то про там про одежду ещё, камеру проверить, и понял что к собеседованиям в реальных технических компаниях это не имеет похоже отношения. И в целом сплошная вода и советы как тратить время впустую вместо искать себе подходящих людей.
Понятнее не стало. Но будем ждать следующую статью: как я построил успешный бизнес с командой агентов.
Ничего не понятно но очень интересно
А что если эта система галлюцинирует? Скажем один агент нагалюцинировал в аналитике(перепутал цифры), потом эта маленькая неточность по цепочке превращается в снежный ком и в итоге получаем неверное стратегическое решение. Без системы которая на 100% исключит эффект галлюцинаций этим пользоваться опасно.
PS: опять же если верификатора на верификатора начнем добавлять, то снежным комом вырастет цена любого решения.
Я вам наверно уже надоел, но позвольте ещё позанудствую: в примере с прямоугольником и квадратом все от требований зависит. Ваш пример искусственный. Если мы смотреть на него в общем смысле, то поведение SetB, SetA и GetS(), скрыты и могут быть какими угодно, гарантий что сделав SetB он не посинеет и не взорвется нет никаких. Так же GetS() никак не зависит от реализации вызовов SetA, SetB иначе мы раскрываем слишком много знаний, важно что у него есть GetS и мы можем его вызвать. В любом случае если в конкретной модели квадрат не может быть прямоугольником то и не нужно его таковым делать. Так же не вижу ничего плохого в "ничего не делать" для воина, так как во-первых это ничего не ломает, во-вторых мы всё-таки что-то сделаем, например кинем Событие и возможно покажем игроку уведомление.
Прошу прощения цикл статей ещё не читал, но все же спрошу, а чем плох вариант когда Игрок.Взять(Оружие) просто ничего не делает(если он Воин и оружие Посох-dynamic cast, либо добавляем ВзятьОружие через паттерн Визитор)?
Если вдруг на пол пути захочется условно из РПГ сделать FPS, то да тут ООП пасс :) да тут и нет простого пути. Любая модульность будь то ООП либо просто разбиение кода по си файлам уже вносят структуру, а любую структуру ломать тяжело, кроме конечно самой базовой(гейм луп, графика, физика, звук, управление).
В тех фреймворках в которых я работал, поддержка языков уже встроена или добавляется с пол пинка. Ну например WPF, или старый добрый WinForms. Все тексты уже лежат в ресурсах на нужных формах в 90% . Нужен новый язык, создаётся новый условно пакет форм и там можно рисовать новый язык и даже внешний вид. Поэтому я и поинтересовался на чем вы так споткнулись?
Если я правильно помню этот принцип, то грубо говоря он выставляет нам только одно требование: использование любого наследника в качестве базового класса, не должно ломать программу, то есть неважно какого наследника мы подсунем, поведение кода не будет сломано. Если алгоритму все равно, маг это или воин, то и принцип не нарушается. Например, рендеру все равно кто это, главное чтобы у него например был метод draw, например. Там где есть разница, там и принимать нужно либо мага либо воина.
Касательно цен, то можно и не прокидывать в каждую функцию новый параметр, как вариант можно DI контейнеры использовать, в корпоративе это по-моему уже мастхэв в проектах.
А можно тут подробнее, чем принцип Лисков плох? И зачем наследовать квадрат от прямоугольника? )
А на чем гуй писали если не секрет, я просто не припомню когда мне последний раз требовалось тексты в коде хранить. Обычно это либо XML, HTML либо встроенный ещё какой либо формат независимый от кода, поддерживаемый фреймворком.
А что у вас тексты прям захардкожены были? А цены тоже?
Ну вот не знаю, у нас в корпоративном секторе все хорошо относительно. Примерно понятна архитектура, понятно какие будут бизнес энтити и бизнес правила. Опять же DDD подход сильно упрощает реакцию на неожиданные требования. Опять же хорошее знание паттерны проектирования, многие проблемы с ООП снимает ещё на старте. Поэтому для меня начало статьи где описывалась объектная модель игры и проблемы подхода показались немного детскими.