Кстати, можете поделиться с какими инструментами получились такие диффы? У меня под claude code почти всегда противположная проблема, генерирует постоянно новый код, почти не меняя существующий, что приводит к разрастанию код базы которую в итоге нужно отдельно. Ну и в целом добавление только 100 линей кода для новой фичи это скорее хороший результат, проект не разрастается, контекст остаётся маленьким.
Я попробовал claude с sonnet 5, лучший инструмент был бы fable но токенов жалко. Вот так получилось.
Скриншоты
Промт вот такой
Скрытый текст
Use subagent to find good samples of grass in the games. Investigate how they are drawn and how we can do it via shader. then create scene webgl with field of grass with some flowers, ensuring high quality and near photorealism. you cant download any textures but do freely generate configs or textures on your owns. take screenshots and iterate until u feel like grass is at least 80% close to AAA games
Тут некое противоречие видется. В первом посте вы рассматриваете что предприятие от использования ИИ уходит в небольшой минус либо остается при своих. То есть ИИ менее экономически эффективен чем люди иьи равен. Тогда конкурирующее предприятие за счёт падение зарплат останется в плюсе, ИИ предприятие уменьшит долю на рынке и проиграет. Ежели и без падения зарплат они наравне.
А вот ежели ИИ эффективнее чем люди во всех областях и намного так что экономической стабильности не будет никакой, то и предсказать что то затруднительно. Думается что деньги потеряют смысл, рынка обычного больше не будет (так как и работы больше не будет), важнее всего будет доступ к ресурсами. Ну и тут акционеры навряд ли превратятся в единственных богачей контролирующих мир. Доступ к оружию, контроль над источниками энергии, заводами видеокарт и тд будет решать все.
По поводу отсутствия понимания сколько денег тратится. У меня тоже коллега на Cursor жаловался на это. Может, стоит попробовать подключить что то вроде https://github.com/helicone/helicone ? То есть пересылать все запросы через прокси которое будет подсчитывать сколько денег тратишь. А если немного повайбкодить, наверное несложно и лимиты на сессии добавить, что если тратишь больше X долларов в последние Y часов, то запрос отклоняется.
Сам я на claude сижу, но если вдруг cursor по каким то причинам очень нужен, наверное это не очень сложно пофиксить?
Потому что мне интересна не только реакция "нравится / не нравится игра", а техническая проверка: где такая архитектура выглядит разумной, а где я сам себе построил бетонный гроб.
Попытался оценить\почитать статью но что-то больше вопросов чем комментов.
Вообще раз уж статья уже о "вайб кодинге", я бы посоветовал хотя бы статью писать руками, выглядело бы получше.
Многие мои вопросы как раз поэтому больше к кривым формулировкам не несущим никакого смысла чем о статье, была бы написана по настоящему может дискуссия вышла бы интересней.
Рейкастер вместо честного 3D
Честный 3D был бы красивее. Еще он был бы дороже, тяжелее, дольше и потребовал бы другой pipeline.
А чего не честного в рекйастинге? Рейкастинг это просто запуск лучей, это вполне себе часть честного 3д. Судя по всему вы имели в виду систему билбординга. Где все персонажи это спрайт который всегда на игрока повернут.
В начале новой игры создается большой пул процедурных жителей. На активном этаже материализуется только нужная часть: живые NPC, их инвентарь, отношения, фракции, занятия, смерть, память о событиях. Остальные остаются компактными записями, а не симулируются покадрово в фоне.
Если честно вообще не понятно о чем речь идет. Не все рендерятся? Они сгенерированы но "замарожены"? В чем разница генерации когда нужно против генерации с самого начала?
Что болит
Первый запуск. Интерфейс. Читаемость. Темп вылазки. Плотность текста. Баланс между «я ничего не понимаю» и «я хочу разобраться».
Системы уже умеют больше, чем новый игрок способен принять за первые десять минут. Это типичная болезнь игры, которая долго росла изнутри: разработчик видит связи, игрок видит шум.
Поэтому сейчас приоритет не в том, чтобы добавить еще двадцать монстров. Приоритет в том, чтобы один живой путь был понятен:
проснулся в жилой зоне;
взял еду, воду, патроны;
понял ближайшую зацепку;
вышел в вылазку;
получил опасность;
принял решение;
вернулся или умер с понятной причиной.
Когда этот путь работает, поверх него можно строить странность. Когда он не работает, вся процедурность превращается в дым.
Я попытался поиграть но чет вообще не понятно о чем игра и что делать надо. В первые 3-4 минут ничего не произошло ни зацепило. Поговорил, получил задание, побродил. Где оружейния не понятно, зачем я там тоже не понятно. Врагов, движа не увидел.
Миникарта есть но кстати тоже сложно читаемая, стенки сливаются с разными текстурами пола.
Отдельно смешно, что самая тяжелая работа оказалась не в «сделать монстра», а в «сделать так, чтобы игрок понял, что сейчас вообще можно делать».
Не понятно чего тут смешного, но логично. Фичи нужно минимизировать и полировать, а не генерировать больше и больше.
Поэтому базовое правило проекта стало таким: ноль runtime‑зависимостей, один браузерный билд, максимум данных и поведения из кода.
Это сильно отрезвляет. Если у тебя нет папки с ассетами, то текстуры должны родиться процедурно. Если нет нормального 3D‑движка, то камера и мир должны быть достаточно простыми, чтобы держаться на raycasting и фейках. Если нет ECS‑библиотеки, то сущности должны быть плоскими объектами, а мир — typed arrays и маленькие регистры.
Опять все это выглядит как то бесмысленно. Если нет ECS то нельзя рендерить не билборды? или о чем речь идет?
И вернемся к
Потому что мне интересна не только реакция "нравится / не нравится игра", а техническая проверка: где такая архитектура выглядит разумной, а где я сам себе построил бетонный гроб.
О какой архитектуре речь идет не понятно, в статье практически ничего о ней не сказано, исходников тоже не видно.
Вообще тема мне немного близка. В индустрии давно работаю и делаю себе проект для души тоже.
Тоже выбрал браузер для input-output но вся логика на бэкенде .net. То есть, есть webserver который всю логику обрабатывает и браузер который все рендерит. Идея в том, что браузер легко использовать как часть интеграции автоматических тестов (с помощью playwright), итерации намного быстрее чем в Unity. Идея в том чтобы в итоге если взлетело можно будет очень легко перенести на Unity. Unity-подход также диктует и сносную архитектуру рендеринга, компоненты, game objects, это все.
Полный отход от ассетов имхо это скорее слабость чем что то позитивное. Есть генерация ассетов и они выходят намного лучше в среднем чем генерация их через код. Для 2д билбордов можно использовать pixellab например. Они дешевые и можно тысячи нагенерировать если хочется.
В целом для проекта я бы посоветовал следующее. Меньше фичей, больше внимания к каждой фиче. Сместить фокус на геймдизайн, определить циклы, вовлечение, удержание внимания. Убедиться что игроку в первые 1-3 минуты придется делать что то важное и будет понятно как.
Кстати дебаггинг по идее тоже очень автоматизируем? Немного удивляет почему популярных АИ инструментов для него не видно. Поставить точки останова, почитать значение, прыгать по стеку - все выглядит вполне реализуемо на агентном уровне.
Даже такой случай едва ли покажет что то. Очень быстро привыкаешь действовать на опережение лага. Клик на на кнопку - и начинаешь печатать до того как появляется поле. Кончено если интерфейс непривычный то так не выйдет, но и время на обдумывание что делать при новом интерфейсе наверняка зависит намного сильней от внимательности и скорости пользователя чем от задержки в 100мс.
Зачем так резко? Вы слова из контекста вырываете. Там написано "Наивное решение, (простая рекурсия) ...". Никто не говорит, что вообще все рекурсии\все решения их использующие являются слишком медленными. Там очевидная отсылка к определенному и неэффективному алгоритму. То что вы здесь реализовали очевидно не является этим.
Кстати говоря, я может ошибаюсь, но это выглядит как раз примером динамичного итераивного программирование? То что названо "хорошим" а не "наивным" решением в комментариях.
Попытка делать акцент на количестве ГБ которые утекают выглядит странной. Если приложение течет, то скорее всего утечет в итоге вся память которая доступна. Будь на машине 1ТБ то утечет в конце концов 1ТБ. В прошлом тоже приложения текли и крашились, даже может больше чем сейчас т.к. ручное управление памятью было более распространенным. Так можно найти любое старое приложение с утечкой, запустить на современной машине с 1ТБ и подождать нужное количество времени.
Например, в IE6 были утечки которых сейчас нет https://www.quirksmode.org/blog/archives/2006/04/ie_7_and_javasc.html. О ужас! Раньше код писали хуже, браузер может слить в никуда 1ТБ!
Может разве что текло медленнее тк в среднем на компьютерах было меньше памяти и это заметнее.
Вообщем мой посыл в том, что некоторые анекдотические случаи утечек в современности это плохой показатель того, больше ли сейчас проблем с управлением памяти чем раньше или нет. Было бы интересно провести исследование на эту тему, влияние современных технологий и фреймворков на кол-во утечек в среднем.
А утечки лучше мерить скоростью и воспроизводимостью чем размером.
С одной стороны, чем дольше длится полет, тем больше сжигается топлива, одного из крупнейших расходов, около 25–30% от всех затрат на рейс. С другой стороны, долго лететь, значит платить больше зарплаты экипажу, дольше гонять двигатели, ресурс-то не бесконечный, и задерживать самолет, который мог бы уже выполнять следующий рейс. То есть у времени тоже есть своя цена: дополнительные минуты в пути увеличивают переменные расходы (экипаж, обслуживание, износ). Получается дилемма: можно лететь быстрее и сэкономить время (уменьшить зарплатные и прочие временные расходы), но потратить больше топлива; или лететь медленно, сберечь топливо, но потерять время.
чем дольше длится полет, тем больше сжигается топлива
Я так понимаю, имеется в виду наоборот? Чем дольше длится полет, тем меньше сжигается топлива. В каких то рамках. А то дилеммы так нет: летишь на максимальной скорости, тратишь минимум топлива, платишь минимум экипажу.
Можно еще вот так например: нажимаешь кнопку движения. Персонаж уже смотрит в эту сторону -> тогда двигаешься в сторону кнопки. Еще не смотрит -> тогда поворачивается в сторону кнопки движения. Ну понятно что стрелки они вверх вниз влево вправо а в игре диагонали, но думаю что примерно так будет вполне понятно.
Стиль игры выглядит оригинальным, мне понравилось.
Но вот понять как играть было сложно.
Скрытый текст
По поводу управления (поиграл минут 5, может быть что то не так понял). Пробел выглядит ненужным усложнением, можно было просто сделать что шаг по лестнице работает автоматически. Вращение тоже выглядит ненужным усложнением, есть же только 4 стороны куда двигаться можно, почему бы не сделать стрелка влево двигает всегда влево и т.д.? тогда чтобы пойти куда то вместо Разворот -> движение вперед просто нужно будет нажать 1 кнопку. Если хочется чтобы персонаж вращался, то можно сделать чтобы всегда смотрел в сторону последнего движения.
Кроме того, вначале показано управление на первом экране. Но судя по всему оно больше никогда не показано. То есть ожидается от игрока что она запомнит все hot keys до начала игры. Это нереалистично. Можно было бы оставить на игровом экране, там места полно. Можно сделать возможно минимизации.
Еще, вот это выглядит как часть уровня и сбивает столку. Думаю лучше было бы поставить сверху и подальше, или еще как нибудь выдлить что это HUD а не часть уровня. Ну или можно уровень жизни показать прямо на персонаже, меняя его цвет или количество его кубов или что угодно.
Еще было довольно сложно понять что желтое - предметы с которыми можно взаимодействовать. Было бы неплохо что когда подходишь подсвечивается кнопка взаимодействия или что то в этом роде. И начать игру с небольшего "туториала". Под туториалом имею в виду ситуации когда игроку просто придется познакомиться с управлением, желтый куб который блокирует движение пока не поднимишь его, каким то способом заставить провзаимодействовать с предметом в инвентаре и т.д.
"У преступности есть раса" против "У преступности есть пол". Интерпретирую первую как "Насколько выше вероятность быть убийцей если ты чернокожий" и "Насколько выше вероятность быть убийцей если ты мужчина". Не очень понятно в чем будет польза считать по отдельности каждую категорию.
Кстати, можете поделиться с какими инструментами получились такие диффы? У меня под claude code почти всегда противположная проблема, генерирует постоянно новый код, почти не меняя существующий, что приводит к разрастанию код базы которую в итоге нужно отдельно. Ну и в целом добавление только 100 линей кода для новой фичи это скорее хороший результат, проект не разрастается, контекст остаётся маленьким.
https://github.com/gzatravkin/GrassSimulation https://gzatravkin.github.io/GrassSimulation/
Я попробовал claude с sonnet 5, лучший инструмент был бы fable но токенов жалко. Вот так получилось.
Скриншоты
Промт вот такой
Скрытый текст
Use subagent to find good samples of grass in the games. Investigate how they are drawn and how we can do it via shader. then create scene webgl with field of grass with some flowers, ensuring high quality and near photorealism. you cant download any textures but do freely generate configs or textures on your owns. take screenshots and iterate until u feel like grass is at least 80% close to AAA games
Тут некое противоречие видется. В первом посте вы рассматриваете что предприятие от использования ИИ уходит в небольшой минус либо остается при своих. То есть ИИ менее экономически эффективен чем люди иьи равен. Тогда конкурирующее предприятие за счёт падение зарплат останется в плюсе, ИИ предприятие уменьшит долю на рынке и проиграет. Ежели и без падения зарплат они наравне.
А вот ежели ИИ эффективнее чем люди во всех областях и намного так что экономической стабильности не будет никакой, то и предсказать что то затруднительно. Думается что деньги потеряют смысл, рынка обычного больше не будет (так как и работы больше не будет), важнее всего будет доступ к ресурсами. Ну и тут акционеры навряд ли превратятся в единственных богачей контролирующих мир. Доступ к оружию, контроль над источниками энергии, заводами видеокарт и тд будет решать все.
А чего не так с показать swagger с json? И погонять реквесты? Комиссия недостаточно технически прошарена или что?
По поводу отсутствия понимания сколько денег тратится. У меня тоже коллега на Cursor жаловался на это. Может, стоит попробовать подключить что то вроде https://github.com/helicone/helicone ? То есть пересылать все запросы через прокси которое будет подсчитывать сколько денег тратишь. А если немного повайбкодить, наверное несложно и лимиты на сессии добавить, что если тратишь больше X долларов в последние Y часов, то запрос отклоняется.
Сам я на claude сижу, но если вдруг cursor по каким то причинам очень нужен, наверное это не очень сложно пофиксить?
Попытался оценить\почитать статью но что-то больше вопросов чем комментов.
Вообще раз уж статья уже о "вайб кодинге", я бы посоветовал хотя бы статью писать руками, выглядело бы получше.
Многие мои вопросы как раз поэтому больше к кривым формулировкам не несущим никакого смысла чем о статье, была бы написана по настоящему может дискуссия вышла бы интересней.
А чего не честного в рекйастинге? Рейкастинг это просто запуск лучей, это вполне себе часть честного 3д. Судя по всему вы имели в виду систему билбординга. Где все персонажи это спрайт который всегда на игрока повернут.
Если честно вообще не понятно о чем речь идет. Не все рендерятся? Они сгенерированы но "замарожены"? В чем разница генерации когда нужно против генерации с самого начала?
Я попытался поиграть но чет вообще не понятно о чем игра и что делать надо. В первые 3-4 минут ничего не произошло ни зацепило. Поговорил, получил задание, побродил. Где оружейния не понятно, зачем я там тоже не понятно. Врагов, движа не увидел.
Миникарта есть но кстати тоже сложно читаемая, стенки сливаются с разными текстурами пола.
Не понятно чего тут смешного, но логично. Фичи нужно минимизировать и полировать, а не генерировать больше и больше.
Опять все это выглядит как то бесмысленно. Если нет ECS то нельзя рендерить не билборды? или о чем речь идет?
И вернемся к
О какой архитектуре речь идет не понятно, в статье практически ничего о ней не сказано, исходников тоже не видно.
Вообще тема мне немного близка. В индустрии давно работаю и делаю себе проект для души тоже.
Тоже выбрал браузер для input-output но вся логика на бэкенде .net. То есть, есть webserver который всю логику обрабатывает и браузер который все рендерит. Идея в том, что браузер легко использовать как часть интеграции автоматических тестов (с помощью playwright), итерации намного быстрее чем в Unity. Идея в том чтобы в итоге если взлетело можно будет очень легко перенести на Unity. Unity-подход также диктует и сносную архитектуру рендеринга, компоненты, game objects, это все.
Полный отход от ассетов имхо это скорее слабость чем что то позитивное. Есть генерация ассетов и они выходят намного лучше в среднем чем генерация их через код. Для 2д билбордов можно использовать pixellab например. Они дешевые и можно тысячи нагенерировать если хочется.
В целом для проекта я бы посоветовал следующее. Меньше фичей, больше внимания к каждой фиче. Сместить фокус на геймдизайн, определить циклы, вовлечение, удержание внимания. Убедиться что игроку в первые 1-3 минуты придется делать что то важное и будет понятно как.
Ссылка посмешила. Но в сегодняшнем контексте статья на хабре выглядит слишком реалистично, без тэга не понять.
Кстати дебаггинг по идее тоже очень автоматизируем? Немного удивляет почему популярных АИ инструментов для него не видно. Поставить точки останова, почитать значение, прыгать по стеку - все выглядит вполне реализуемо на агентном уровне.
Даже такой случай едва ли покажет что то. Очень быстро привыкаешь действовать на опережение лага. Клик на на кнопку - и начинаешь печатать до того как появляется поле. Кончено если интерфейс непривычный то так не выйдет, но и время на обдумывание что делать при новом интерфейсе наверняка зависит намного сильней от внимательности и скорости пользователя чем от задержки в 100мс.
Зачем так резко? Вы слова из контекста вырываете. Там написано "Наивное решение, (простая рекурсия) ...". Никто не говорит, что вообще все рекурсии\все решения их использующие являются слишком медленными. Там очевидная отсылка к определенному и неэффективному алгоритму. То что вы здесь реализовали очевидно не является этим.
Кстати говоря, я может ошибаюсь, но это выглядит как раз примером динамичного итераивного программирование? То что названо "хорошим" а не "наивным" решением в комментариях.
Попытка делать акцент на количестве ГБ которые утекают выглядит странной. Если приложение течет, то скорее всего утечет в итоге вся память которая доступна. Будь на машине 1ТБ то утечет в конце концов 1ТБ. В прошлом тоже приложения текли и крашились, даже может больше чем сейчас т.к. ручное управление памятью было более распространенным. Так можно найти любое старое приложение с утечкой, запустить на современной машине с 1ТБ и подождать нужное количество времени.
Например, в IE6 были утечки которых сейчас нет https://www.quirksmode.org/blog/archives/2006/04/ie_7_and_javasc.html. О ужас! Раньше код писали хуже, браузер может слить в никуда 1ТБ!
Может разве что текло медленнее тк в среднем на компьютерах было меньше памяти и это заметнее.
Вообщем мой посыл в том, что некоторые анекдотические случаи утечек в современности это плохой показатель того, больше ли сейчас проблем с управлением памяти чем раньше или нет. Было бы интересно провести исследование на эту тему, влияние современных технологий и фреймворков на кол-во утечек в среднем.
А утечки лучше мерить скоростью и воспроизводимостью чем размером.
Я так понимаю, имеется в виду наоборот? Чем дольше длится полет, тем меньше сжигается топлива. В каких то рамках. А то дилеммы так нет: летишь на максимальной скорости, тратишь минимум топлива, платишь минимум экипажу.
Можно еще вот так например: нажимаешь кнопку движения. Персонаж уже смотрит в эту сторону -> тогда двигаешься в сторону кнопки. Еще не смотрит -> тогда поворачивается в сторону кнопки движения. Ну понятно что стрелки они вверх вниз влево вправо а в игре диагонали, но думаю что примерно так будет вполне понятно.
Стиль игры выглядит оригинальным, мне понравилось.
Но вот понять как играть было сложно.
Скрытый текст
По поводу управления (поиграл минут 5, может быть что то не так понял). Пробел выглядит ненужным усложнением, можно было просто сделать что шаг по лестнице работает автоматически. Вращение тоже выглядит ненужным усложнением, есть же только 4 стороны куда двигаться можно, почему бы не сделать стрелка влево двигает всегда влево и т.д.? тогда чтобы пойти куда то вместо Разворот -> движение вперед просто нужно будет нажать 1 кнопку. Если хочется чтобы персонаж вращался, то можно сделать чтобы всегда смотрел в сторону последнего движения.
Кроме того, вначале показано управление на первом экране. Но судя по всему оно больше никогда не показано. То есть ожидается от игрока что она запомнит все hot keys до начала игры. Это нереалистично. Можно было бы оставить на игровом экране, там места полно. Можно сделать возможно минимизации.
Еще, вот это выглядит как часть уровня и сбивает столку. Думаю лучше было бы поставить сверху и подальше, или еще как нибудь выдлить что это HUD а не часть уровня. Ну или можно уровень жизни показать прямо на персонаже, меняя его цвет или количество его кубов или что угодно.
Еще было довольно сложно понять что желтое - предметы с которыми можно взаимодействовать. Было бы неплохо что когда подходишь подсвечивается кнопка взаимодействия или что то в этом роде. И начать игру с небольшего "туториала". Под туториалом имею в виду ситуации когда игроку просто придется познакомиться с управлением, желтый куб который блокирует движение пока не поднимишь его, каким то способом заставить провзаимодействовать с предметом в инвентаре и т.д.
А как узнать иначе что ничего не сломалось? И оценить. Вопрос тут известно llm о тестах
Кстати странно что никто в этой ветке ещё не погулил. Были петиции об этом. (По крайней мере одна). Было бы странно если бы не было, петиций огромное количество. https://www.change.org/p/государственной-думе-рф-министерству-труда-и-социальной-защиты-рф-отменить-запрет-на-456-профессий-для-женщин
Фильма про преодоление запрета работать в шахтах не нашёл, но про запрет работе пожарной был. https://itvs.org/films/taking-the-heat/
По идее должно быть тоже самое. Согласно той же статистике https://ucr.fbi.gov/crime-in-the-u.s/2019/crime-in-the-u.s.-2019/tables/expanded-homicide-data-table-3.xls
После удельных преобразований получается
Чёрные мужчины: ≈ 28.7 на 100k
Белые мужчины: ≈ 4.28 на 100k
Чёрные женщины: ≈ 3.6 на 100k
Белые женщины: ≈ 0.57 на 100k
То есть такой же вывод.
Вы раньше говорили о том что черных женщине > белые мужчины, судя по всему значения меняются достаточно сильно год от года (или регион от региона).
То есть пол и раса влияют плюс минус одинаково.
Почему? У нас тут две фразы.
"У преступности есть раса" против "У преступности есть пол". Интерпретирую первую как "Насколько выше вероятность быть убийцей если ты чернокожий" и "Насколько выше вероятность быть убийцей если ты мужчина". Не очень понятно в чем будет польза считать по отдельности каждую категорию.
Кстати посчитал. Все же пол влияет на вероятность быть задержанным за убийство (другой статистики нет) сильней чем раса. Статистика по США за 2019. https://ucr.fbi.gov/crime-in-the-u.s/2019/crime-in-the-u.s.-2019/topic-pages/tables/table-43 https://ucr.fbi.gov/crime-in-the-u.s/2019/crime-in-the-u.s.-2019/tables/table-42/table-42.xls
Быть мужчиной повышает шансы ареста за убийство в 7.57 раз, быть черным (мужчиной либо женщиной) в 6.29.
А в целом показатели схожие и оба выражения звучат сомнительно.