Я сам не пишу код руками уже 4 месяца, вообще. Но при этом, я вижу вокруг себя ущерб от AI, который неуместно даже озвучивать на созвонах.
Если подходить с умом, и оценивать здраво, то ускорение есть, особенно на утилитах и рутине, где не нужна поддержка, и можно переписать заново в любой момент. Если фанатично и без адекватной оценки рисков натягивать сову на многомиллионный burn-rate, то это дурь.
Мы как раз об одном и том же и говорим. После примеров с калькуляторами и одно-файловыми скриптами, эйфория заканчивается и начинается разрушение компаний, если просто экстраполировать.
Дело совершенно не в способе, а в используемых буквах. У вас просто бессмыслица в некоторых предложениях, которые человек бы не написал сам ни за что в жизни, и это не очень красиво по отношению к читателю. Я специально пишу об этом в публичном комменте, чтобы отвечать своей кармой за слова. Такие статьи на хабре надо минусовать с соответствующей категорией. Ничего личного, содержание статьи которое я смог уловить и правда полезное.
ИИ в этой схеме — ещё один участник команды, а не отдельный волшебный режим.
Достаточно, спасибо. К сожалению, эта же статья, написаная ЛЛМ, могла быть полезной, если бы была написана традиционным способом. Зря вы так относитесь к своему контенту.
Side effects - могут быть полезны, если сделать всё правильно - чтобы расчёт тика никогда не зависел от сайд эффекта. Например, в ECS не очень удобно работать с событиями, которые происходят только 1 раз, и нужны только для визуализации. Например, получение ачивки игроком. В таких случаях мы в проекте делаем каналы связи в одну сторону, вопреки Data-Oriented Design, но никогда расчёт тика от этих данных не зависит, мы даже прочитать назад эти данные из ECS системы не можем, там интерфейсами прикрыто везде.
Другой пример - это логгирование или аналитика, тоже так норм делать.
Наверное тогда это ответ - да. Side effects - это как раз термин, который означает модификацию данных вне основного расчёта или расположение части данных вне "тикового слепка".
Хорошо что их нет. Для расчёта логики по тикам, отсутствие сайд эффектов это очень важно для тестируемости, воспроизводимости, и для крутых сетевых фишек в будущем, таких как лаг-компенсация.
Ну и самое главное, путем каталогирования ссылок на эти все гугл документы, дизайнеры, очевидно, изобрели гит и гитмердж, только полностью в ручном режиме, со всеми ручными рисками ошибок.
JSON в гите, там где данные очень древовидные и имеют опциональные ветви.
Табличные файлы (в основном в гугле) - Там хранится 2д табличный формат, заранее продуманый программистом для каждого листа, и который не планируется менять. Например, цены в магазинах, календарь эвентов или акций. Там у нас тоже только экспорт.
Но я в нашей компании был против п.2, тк теперь вся безопасность конфигов, их тестирование и бекпорт фиксов легли на сторону нетехнарей. Хотя большую часть вещей можно было бы проверять автоматизировано. Как по мне, проще доразвить вариант из п.1, сохранив надежность, чем делать что-то разваливающееся и чинить потом только руками.
У вас первоисточником данных теперь являются эксель/гугл файлы? У вас дизайнеры еще не переизобрели гит случаем?
Это тупиковый путь развития, если есть только экспорт, и нет импорта обратно.
Первоисточник может лежать только в паре с исходным кодом, так как настоящая схема данных это и есть код. Любое изменение в дереве связей синхронизировано с кодом, и перестает быть совместимым если ошибиться.
После 30 версий и одновременных хотфиксов старых версий в проде, у вас будут бесчисленные каталоги ссылок на все версии документов, заполненные руками, и ручной мердж и бекпорт всех изменений по этим каталогам в обратную сторону. Так работать нежелательно...
Если есть возможность хранить джейсоны в гите, и только для редактирования временно доставать в таблицы, то это может быть решением.
Для недетерменированных схем не нужен точный float, достаточно квантизировать по одному и тому же алгоритму, тк если хотя бы квантизация детерменирована (или имеет средство восстановления), то все остальные расчёты могут спокойно иметь погрешности.
К тому, же, механизм восстановления после расхождения всё равно должен быть и часто работать, так как в сетевой игре мы не можем предсказать других игроков, и их влияние на нас и это всегда мисспредикт.
Но поворот это же конечная величина, которая не зависит от фпс. Игрок в физическом времени подвинул мышку на одно и то же расстояние, и умноженное на чувствительность в градусах - камера в итоге должна повернуться на один и тот же градус, вне зависимости за какое число кадров это произойдет. Если умножать на дельтатайм, то сумма уже может не сойтись.
Да совсем нет, это ввод игрока. Иначе на разных мониторах будет разная чувствительность у одной и той же мышки. + так заложена акселерация, что тоже для шутера сойдет за ошибку.
А почему у вас для поворота камеры используется время? Похоже на ошибку. newCameraRotation.x += inputView.y playerSettings.verticalSensetivity * Time.deltaTime * playerSettings.verticalInverted == true ? 1f : -1f);
А для IVariable типа int в проекте генерируются экстеншны для всех сущностей с таким филдом? Получается будет список из всех методов от всех данных в коде на каждый тип так? Если так, то это быстро станет неюзабельным, тк по имени филда данных будет непонятно, совместим ли он с конкретным behaviour или нет.
А есть ли польза, если совмещать подачу в ллм доступных инструментов и применять Structured Output схему? Например, если ожидается что в этом запросе будут использоваться конкретные методы и только аргументы неизвестны.
Делать игру одному или целой большой командой? Это совсем не главный вопрос. Главное это понять, почему игра мечты не была доделана. Игры делать очень сложно, и умножив сложность на неправильную оценку своих ресурсов и возможностей это приводит к катастрофе. Таким же образом и целые компании не доделывают свои игры. Через год разработки окажется что забыли нанять необходимый отдел, а найм займет пол года. Например, маркетолога, или звуковика.
Делать маленькие игры это хороший треннинг для трезвой работы с ресурсами. Попробуйте запланировать игру за 1 неделю и примите решение какие фичи вы сделать не успеете, зато сделайте другие хорошо.
А ведь это любопытный маркер, когда начинаешь считать такой свитер упоротым, много мыслей сразу всплывает:
Как плюшка от компании он тебе нафиг не нужен, тк знаешь свою реальную зарплату и реальный рынок. Простые плюшки уже не впечатляют.
Не одеть его тоже не очень, тк легко перейти грань "Доктора Хауса" по токсичности, и отбиться от коллектива. Хотябы на общей фоточке засветиться на коропративе надо.
Свитера раздают в устаканившихся и больших организациях где мерч уже рассавлен на поток и значит вы застали такой коллектив и не отвалились на испытательных сроках и команда вас не выпилила.
При этом, чуство вкуса от выгорания не пропало, и свитер становится формой протеста.
А это точно open-source, то что вы имеете в виду? Кажется что если есть желание дать пользу исходным кодом проекта, то лучше сработает опубликованный как есть код и улучшение его через публичные пул-реквесты. Лицензии можно использовать разные.
Я сам не пишу код руками уже 4 месяца, вообще. Но при этом, я вижу вокруг себя ущерб от AI, который неуместно даже озвучивать на созвонах.
Если подходить с умом, и оценивать здраво, то ускорение есть, особенно на утилитах и рутине, где не нужна поддержка, и можно переписать заново в любой момент. Если фанатично и без адекватной оценки рисков натягивать сову на многомиллионный burn-rate, то это дурь.
Мы как раз об одном и том же и говорим. После примеров с калькуляторами и одно-файловыми скриптами, эйфория заканчивается и начинается разрушение компаний, если просто экстраполировать.
Ваш комментарий скорее подтверждает смысл статьи.
Вы:
без продукт-анализа (ведь вы про себя то точно знаете что хочет пользователь),
без экспертизы того на сколько надёжен скрипт ("сейчас работает"),
Даёте оценку продукту:
написанному с нуля (не очень большому скрипту, которые ллм ваншотает),
в котором нет необходимости никак передавать базу знаний или онбордить новичков,
нет необходимости дорабатывать функционал и отвечать карьерой за цельность всех предыдущих фичей
И делаете вывод что проблема в людях, но при этом не в вас?
Дело совершенно не в способе, а в используемых буквах. У вас просто бессмыслица в некоторых предложениях, которые человек бы не написал сам ни за что в жизни, и это не очень красиво по отношению к читателю. Я специально пишу об этом в публичном комменте, чтобы отвечать своей кармой за слова. Такие статьи на хабре надо минусовать с соответствующей категорией. Ничего личного, содержание статьи которое я смог уловить и правда полезное.
Достаточно, спасибо. К сожалению, эта же статья, написаная ЛЛМ, могла быть полезной, если бы была написана традиционным способом. Зря вы так относитесь к своему контенту.
Side effects - могут быть полезны, если сделать всё правильно - чтобы расчёт тика никогда не зависел от сайд эффекта. Например, в ECS не очень удобно работать с событиями, которые происходят только 1 раз, и нужны только для визуализации. Например, получение ачивки игроком. В таких случаях мы в проекте делаем каналы связи в одну сторону, вопреки Data-Oriented Design, но никогда расчёт тика от этих данных не зависит, мы даже прочитать назад эти данные из ECS системы не можем, там интерфейсами прикрыто везде.
Другой пример - это логгирование или аналитика, тоже так норм делать.
Наверное тогда это ответ - да. Side effects - это как раз термин, который означает модификацию данных вне основного расчёта или расположение части данных вне "тикового слепка".
Хорошо что их нет. Для расчёта логики по тикам, отсутствие сайд эффектов это очень важно для тестируемости, воспроизводимости, и для крутых сетевых фишек в будущем, таких как лаг-компенсация.
Ну и самое главное, путем каталогирования ссылок на эти все гугл документы, дизайнеры, очевидно, изобрели гит и гитмердж, только полностью в ручном режиме, со всеми ручными рисками ошибок.
У нас две системы:
JSON в гите, там где данные очень древовидные и имеют опциональные ветви.
Табличные файлы (в основном в гугле) - Там хранится 2д табличный формат, заранее продуманый программистом для каждого листа, и который не планируется менять. Например, цены в магазинах, календарь эвентов или акций. Там у нас тоже только экспорт.
Но я в нашей компании был против п.2, тк теперь вся безопасность конфигов, их тестирование и бекпорт фиксов легли на сторону нетехнарей. Хотя большую часть вещей можно было бы проверять автоматизировано. Как по мне, проще доразвить вариант из п.1, сохранив надежность, чем делать что-то разваливающееся и чинить потом только руками.
У вас первоисточником данных теперь являются эксель/гугл файлы? У вас дизайнеры еще не переизобрели гит случаем?
Это тупиковый путь развития, если есть только экспорт, и нет импорта обратно.
Первоисточник может лежать только в паре с исходным кодом, так как настоящая схема данных это и есть код. Любое изменение в дереве связей синхронизировано с кодом, и перестает быть совместимым если ошибиться.
После 30 версий и одновременных хотфиксов старых версий в проде, у вас будут бесчисленные каталоги ссылок на все версии документов, заполненные руками, и ручной мердж и бекпорт всех изменений по этим каталогам в обратную сторону. Так работать нежелательно...
Если есть возможность хранить джейсоны в гите, и только для редактирования временно доставать в таблицы, то это может быть решением.
На моей практике Blackboard это жестокий антипаттерн. Нет ограничений кто что пишет, и какие сигнатуры у данных. Не рекомендую.
Для недетерменированных схем не нужен точный float, достаточно квантизировать по одному и тому же алгоритму, тк если хотя бы квантизация детерменирована (или имеет средство восстановления), то все остальные расчёты могут спокойно иметь погрешности.
К тому, же, механизм восстановления после расхождения всё равно должен быть и часто работать, так как в сетевой игре мы не можем предсказать других игроков, и их влияние на нас и это всегда мисспредикт.
Но поворот это же конечная величина, которая не зависит от фпс. Игрок в физическом времени подвинул мышку на одно и то же расстояние, и умноженное на чувствительность в градусах - камера в итоге должна повернуться на один и тот же градус, вне зависимости за какое число кадров это произойдет. Если умножать на дельтатайм, то сумма уже может не сойтись.
Да совсем нет, это ввод игрока. Иначе на разных мониторах будет разная чувствительность у одной и той же мышки. + так заложена акселерация, что тоже для шутера сойдет за ошибку.
А почему у вас для поворота камеры используется время? Похоже на ошибку.
newCameraRotation.x += inputView.y playerSettings.verticalSensetivity * Time.deltaTime * playerSettings.verticalInverted == true ? 1f : -1f);А для IVariable типа int в проекте генерируются экстеншны для всех сущностей с таким филдом? Получается будет список из всех методов от всех данных в коде на каждый тип так? Если так, то это быстро станет неюзабельным, тк по имени филда данных будет непонятно, совместим ли он с конкретным behaviour или нет.
А есть ли польза, если совмещать подачу в ллм доступных инструментов и применять Structured Output схему? Например, если ожидается что в этом запросе будут использоваться конкретные методы и только аргументы неизвестны.
Делать игру одному или целой большой командой? Это совсем не главный вопрос. Главное это понять, почему игра мечты не была доделана. Игры делать очень сложно, и умножив сложность на неправильную оценку своих ресурсов и возможностей это приводит к катастрофе. Таким же образом и целые компании не доделывают свои игры. Через год разработки окажется что забыли нанять необходимый отдел, а найм займет пол года. Например, маркетолога, или звуковика.
Делать маленькие игры это хороший треннинг для трезвой работы с ресурсами. Попробуйте запланировать игру за 1 неделю и примите решение какие фичи вы сделать не успеете, зато сделайте другие хорошо.
>тот самый ублюдский свитер с оленями
А ведь это любопытный маркер, когда начинаешь считать такой свитер упоротым, много мыслей сразу всплывает:
Как плюшка от компании он тебе нафиг не нужен, тк знаешь свою реальную зарплату и реальный рынок. Простые плюшки уже не впечатляют.
Не одеть его тоже не очень, тк легко перейти грань "Доктора Хауса" по токсичности, и отбиться от коллектива. Хотябы на общей фоточке засветиться на коропративе надо.
Свитера раздают в устаканившихся и больших организациях где мерч уже рассавлен на поток и значит вы застали такой коллектив и не отвалились на испытательных сроках и команда вас не выпилила.
При этом, чуство вкуса от выгорания не пропало, и свитер становится формой протеста.
А это точно open-source, то что вы имеете в виду? Кажется что если есть желание дать пользу исходным кодом проекта, то лучше сработает опубликованный как есть код и улучшение его через публичные пул-реквесты. Лицензии можно использовать разные.