Управляемость авто надо очень сильно доделывать, ощущения как от трамвая на рельсах. Как минимум сделать, чтобы вначале нажатия на клавишу поворота автомобиль не сразу "на максимум" поворачивал, а чуть-чуть. Чтобы переход от прямого движения к максимально поворачивающему был плавным и занимал доли секунды.
Ускорение у авто не зависит от скорости и тупо срезано у 140 км/ч. Сопротивления воздуха нет (оно пропорционально квадрату скорости). Это тоже тупо, советую посмотреть на формулу E = mv^2 / 2, и сказать, что ускорение - не константа, а = (Power - с v^3) / max(v, power * k / g)
С бельгийской стороны обратный пример - как можно вбухать кучу сил и средств в строительство форта и потерять его из-за плохой организации и неподготовленного личного состава. Они даже сигнал в виде предупредительных выстрелов нормально подать не смогли.
Они ближе к концу игры появятся. Кажется, их специально не показывают, чтобы игрок сначала создал работающий процессор и только потом начал заморачиваться с улучшениями.
Но при этом оценки игры в стиме "крайне положительные". У неё забавный стиль - как будто действительно работаешь в китайской компании - электронные письма от коллег, задания типа "сделать моргающую лампочку для муляжа камеры", солитер на рабочем столе.
Я примерно за 30 часов дошёл до заданий в avalon city, потом стало как-то слишком сложно и я остановился.
Война закончилась бы на год раньше или позже, в зависимости от его управленческого таланта.
Но бывают же развилки в истории в ключевые моменты, когда какая-нибудь мелочь может поменять всё.
Что если бы война закончилась с другим результатом? А что, если Германия осталась бы союзником СССР и додавила Англию?
Что если из-за какой-нибудь случайности Холодная война превратилась бы в ядерную?
Или совсем другой пример - что если бы Илона Маска бы не было? Были бы starlink и spaceX и ракеты на керосине с корпусом из нержавеющей стали, вместо законстеневшей космической отрасли с дорогими материалами и медленной разработкой?
Можно ли сказать, что глобальный процесс истории сходится? Что если нет?
В MMORPG так и есть, с разницей только в том, что вместо npc там живые игроки.
Есть книжки по геймдизайну виртуальных миров - про баланс, экономику и круговорот ресурсов в ней - чтобы мир мог существовать более-менее устойчиво. Большую часть подходов можно перенести в мир "умных" npc.
По моему опыту, игры с интересным поведением персонажей типа dwarf fortress или rimworld имеют очень схематичную графику и для добавления новой механики зачастую достаточно программиста - действие персонажа не требует анимаций или сложных проверок в 3д.
Да, костыль. Но иногда бывает "надо". Альтернативое решение - взять исходники андроид плагина, поменять их, а потом поддерживать все-все изменения, которые делает гугл. Это тоже ни разу не просто и не красиво.
Если бы офисы были не только в центре, но и в Урюпинске, то официанты могли бы хорошо зарабатывать и там.
Если перетаскивать ресурсы в центр, то их становится меньше во всех остальных местах + есть потери ресурсов на перетаскивание.
Например, в случае Москвы, это транспортные проблемы из-за размера города, когда на работу или в магазин можно добираться час или даже два, а люди каждое утро на электричках и метро едут работать в этот самый центр, чтобы вечером поехать обратно.
Как-то коряво написано. Вроде и верно, но акценты явно не на том расставлены, как будто переводчик не разбирается в теме.
Для интересующих на Хабре есть цикл переводов по open gl: ссылка на одну из последних, в ней открывайте содержание и там ссылки на все предыдущие переводы https://habr.com/ru/articles/473990/
Чтобы выполнить эту трансформацию, мы используем координаты X, Y и Z этой вершины в модельном пространстве, затем положение, масштаб и вращение модели в мировом пространстве и, наконец, координаты и вращение камеры и её поле зрения. Мы подставляем все эти числа в различные матрицы трансформации и перемножаем их, получая значения X и Y вершины на экране просмотра, а также значение Z или глубину, которую мы будем использовать позже для определения перекрытия объектов.
Ну отвратительно же написано. Хотя сама идея в 3д графике красивая - каждое преобразование (перемещение, поворот, масштабирование, проективная проекция) представлена в виде матрицы 4х4 и комбинация произвольного количества матриц будет тоже матрицей.
Поэтому, чтобы максимально эффективно пересчитывать координаты вершин, для модели можно один раз найти произведение матриц и потом умножить вектор каждой вершины на неё.
Или например про сглаживание - SSAA конечно существует, но плохо сочетается с отложенным рендерингом и в современных играх используются другие подходы.
Аналогично в gradle есть стандартные задачки для копирования, скачивания файлов и со вполне декларативным описанием.
Но иногда хочется чего-то нестандартного.
Например, существует плагин для компиляции скалы 2.11 под android - он ждёт, когда андроид плагин соберёт граф зависимостей между задачами и добавляет новых задач, в которых вместо компилятора java начинает вызываться компилятор scala. Задачки со сборкой java остаются, но у них аккуратно отключают (заменяют список входных файлов на пустой и добавляют зависимость от компиляции scala)
Сам андроид плагин в зависимости от конфигурации создаёт целую кучу задачек компиляции и именно гибкость и динамичность старого gradle позволяла их модифицировать без больших мучений.
Как вариант для быстрой проверки - можно было сконвертировать байты в hex-строки, отсортировать и просто глазами посмотреть. И то же самое, но с функцией сравнения строк с конца (просто сравнивать по reverse(s)).
Вариант с деревом хорош, но иногда и более простые в реализации способы тоже работают.
На танке Т-34 стоит двигатель В-2, который изначально хотели использовать в авиации. И уже в тридцатых годах сделали двигатель из алюминия, с верхним расположением двух распредвалов на каждый ряд цилиндров, с непосредственным впрыском и сухим картером. Но он оказался всё недостаточно мощным и на самолётах его толком не использовали.
У Кнута есть книжка "Дискретная математика", там очень красиво рассказывается про аналогии между интегралом и суммой ряда. И в другую сторону тоже - элементы ряда это аналоги производной от суммы ряда. И заодно красиво переносятся теоремы и подходы для решения задач.
Есть некоторые отличия - например, для непрерывной функции производная считается по бесконечно малой окрестности точки, а для ряда так не прокатит, там шаг останется либо в +1, либо в -1 (и производная ряда "слева" может отличаться от производной "справа").
Вы в своём способе как раз написали производную от суммы ряда)
там помимо JB IDEA есть другое название — Pycharm. это вполне себе идентифицирует конкретный продукт
Замечу, что продукт называется PyCharm. Не знаю, насколько юридически важна заглавная буква, но текущее написание на сайте выглядит либо как халатность и небрежность, либо как намеренное изменение. По ошибке в каждом из названий выглядит очень подозрительно.
Есть ли необходимость реализации в поисковом модуле Хабра механизмов, использующих метрики, которые описаны в этой статье?
Есть необходимость в публичном API хабра, чтобы подобный поисковик и прочие идеи желающие люди могли реализовать сами.
Я в 2019 году попробовал написать бота для телеги, чтобы он выбирал интересное. "Общение с хабром" - костыльный парсинг html странички и попытки вытащить оттуда рейтинг и прочую статистику. А чтобы отследить, например, статистику в динамике, вообще надо было раз за разом перепроверять каждую публикацию. И само собой со временем разметка страницы может меняться и код для парсинга придётся исправлять. Это ужасный подход, но без официального API другого способа и нет.
Про графики - при помощи логарифма эспонента превращается в прямую, а прямую даже на глаз очень хорошо видно.
Управляемость авто надо очень сильно доделывать, ощущения как от трамвая на рельсах.
Как минимум сделать, чтобы вначале нажатия на клавишу поворота автомобиль не сразу "на максимум" поворачивал, а чуть-чуть. Чтобы переход от прямого движения к максимально поворачивающему был плавным и занимал доли секунды.
Ускорение у авто не зависит от скорости и тупо срезано у 140 км/ч. Сопротивления воздуха нет (оно пропорционально квадрату скорости). Это тоже тупо, советую посмотреть на формулу E = mv^2 / 2, и сказать, что ускорение - не константа, а = (Power - с v^3) / max(v, power * k / g)
Впечатляет уровень подготовки операции.
С бельгийской стороны обратный пример - как можно вбухать кучу сил и средств в строительство форта и потерять его из-за плохой организации и неподготовленного личного состава. Они даже сигнал в виде предупредительных выстрелов нормально подать не смогли.
Они ближе к концу игры появятся. Кажется, их специально не показывают, чтобы игрок сначала создал работающий процессор и только потом начал заморачиваться с улучшениями.
Это будет медленнее по задержкам, потому что надо ждать, когда сигнал от carry пройдёт последовательно через каждый блок add.
Собрал префиксный сумматор, задержка 18
А вообще прикольно, я всю игру по наитию собирал, теперь попробую вооружиться книжкой и собрать всё "по-науке" :)
Мне кажется, собирать и отлаживать процессор в Майнкрафте на редстоуне сильно сложнее. Я бы не взялся за такое без опыта, полученного в чём-то ещё.
Но при этом оценки игры в стиме "крайне положительные". У неё забавный стиль - как будто действительно работаешь в китайской компании - электронные письма от коллег, задания типа "сделать моргающую лампочку для муляжа камеры", солитер на рабочем столе.
Я примерно за 30 часов дошёл до заданий в avalon city, потом стало как-то слишком сложно и я остановился.
Но бывают же развилки в истории в ключевые моменты, когда какая-нибудь мелочь может поменять всё.
Что если бы война закончилась с другим результатом? А что, если Германия осталась бы союзником СССР и додавила Англию?
Что если из-за какой-нибудь случайности Холодная война превратилась бы в ядерную?
Или совсем другой пример - что если бы Илона Маска бы не было? Были бы starlink и spaceX и ракеты на керосине с корпусом из нержавеющей стали, вместо законстеневшей космической отрасли с дорогими материалами и медленной разработкой?
Можно ли сказать, что глобальный процесс истории сходится? Что если нет?
В MMORPG так и есть, с разницей только в том, что вместо npc там живые игроки.
Есть книжки по геймдизайну виртуальных миров - про баланс, экономику и круговорот ресурсов в ней - чтобы мир мог существовать более-менее устойчиво. Большую часть подходов можно перенести в мир "умных" npc.
По моему опыту, игры с интересным поведением персонажей типа dwarf fortress или rimworld имеют очень схематичную графику и для добавления новой механики зачастую достаточно программиста - действие персонажа не требует анимаций или сложных проверок в 3д.
Да, костыль. Но иногда бывает "надо".
Альтернативое решение - взять исходники андроид плагина, поменять их, а потом поддерживать все-все изменения, которые делает гугл. Это тоже ни разу не просто и не красиво.
Если бы офисы были не только в центре, но и в Урюпинске, то официанты могли бы хорошо зарабатывать и там.
Если перетаскивать ресурсы в центр, то их становится меньше во всех остальных местах + есть потери ресурсов на перетаскивание.
Например, в случае Москвы, это транспортные проблемы из-за размера города, когда на работу или в магазин можно добираться час или даже два, а люди каждое утро на электричках и метро едут работать в этот самый центр, чтобы вечером поехать обратно.
По-моему его можно назвать мёртвым кодом (dead code)
Или разница в том, что footloose код всё-таки исполняется, но ни на что не влияет?
Как-то коряво написано. Вроде и верно, но акценты явно не на том расставлены, как будто переводчик не разбирается в теме.
Для интересующих на Хабре есть цикл переводов по open gl: ссылка на одну из последних, в ней открывайте содержание и там ссылки на все предыдущие переводы https://habr.com/ru/articles/473990/
Ну отвратительно же написано. Хотя сама идея в 3д графике красивая - каждое преобразование (перемещение, поворот, масштабирование, проективная проекция) представлена в виде матрицы 4х4 и комбинация произвольного количества матриц будет тоже матрицей.
Поэтому, чтобы максимально эффективно пересчитывать координаты вершин, для модели можно один раз найти произведение матриц и потом умножить вектор каждой вершины на неё.
Или например про сглаживание - SSAA конечно существует, но плохо сочетается с отложенным рендерингом и в современных играх используются другие подходы.
Аналогично в gradle есть стандартные задачки для копирования, скачивания файлов и со вполне декларативным описанием.
Но иногда хочется чего-то нестандартного.
Например, существует плагин для компиляции скалы 2.11 под android - он ждёт, когда андроид плагин соберёт граф зависимостей между задачами и добавляет новых задач, в которых вместо компилятора java начинает вызываться компилятор scala. Задачки со сборкой java остаются, но у них аккуратно отключают (заменяют список входных файлов на пустой и добавляют зависимость от компиляции scala)
Сам андроид плагин в зависимости от конфигурации создаёт целую кучу задачек компиляции и именно гибкость и динамичность старого gradle позволяла их модифицировать без больших мучений.
Как вариант для быстрой проверки - можно было сконвертировать байты в hex-строки, отсортировать и просто глазами посмотреть. И то же самое, но с функцией сравнения строк с конца (просто сравнивать по reverse(s)).
Вариант с деревом хорош, но иногда и более простые в реализации способы тоже работают.
Физику можно и чаще считать, в автосимуляторах видел цифры порядка 400- 1600 шагов физики в секунду.
Но в остальных играх высокая точность не сильно нужна, достаточно чтобы оно выглядело более-менее правдоподобно.
На танке Т-34 стоит двигатель В-2, который изначально хотели использовать в авиации. И уже в тридцатых годах сделали двигатель из алюминия, с верхним расположением двух распредвалов на каждый ряд цилиндров, с непосредственным впрыском и сухим картером. Но он оказался всё недостаточно мощным и на самолётах его толком не использовали.
У Кнута есть книжка "Дискретная математика", там очень красиво рассказывается про аналогии между интегралом и суммой ряда. И в другую сторону тоже - элементы ряда это аналоги производной от суммы ряда. И заодно красиво переносятся теоремы и подходы для решения задач.
Есть некоторые отличия - например, для непрерывной функции производная считается по бесконечно малой окрестности точки, а для ряда так не прокатит, там шаг останется либо в +1, либо в -1 (и производная ряда "слева" может отличаться от производной "справа").
Вы в своём способе как раз написали производную от суммы ряда)
Замечу, что продукт называется PyCharm. Не знаю, насколько юридически важна заглавная буква, но текущее написание на сайте выглядит либо как халатность и небрежность, либо как намеренное изменение.
По ошибке в каждом из названий выглядит очень подозрительно.
Есть необходимость в публичном API хабра, чтобы подобный поисковик и прочие идеи желающие люди могли реализовать сами.
Я в 2019 году попробовал написать бота для телеги, чтобы он выбирал интересное. "Общение с хабром" - костыльный парсинг html странички и попытки вытащить оттуда рейтинг и прочую статистику. А чтобы отследить, например, статистику в динамике, вообще надо было раз за разом перепроверять каждую публикацию. И само собой со временем разметка страницы может меняться и код для парсинга придётся исправлять. Это ужасный подход, но без официального API другого способа и нет.
Бота я по-факту перестал использовать, но статью написал и там есть ссылки на код: https://habr.com/ru/articles/475450/