Теперь только и надо что следить за лапами

Кстати, интересный моментик с Balatro состоит в том, что игра на движке LÖVE, код на Lua.

Вы буквально можете открыть exe'шник 7zip'ом и менять код игры как вам захочется.

#Balatro #LÖVE

Про логические уловки.

Люди довольно часто, осознано, или нет, оставим это на их совести, пользуются логическими уловками.

3 моих любимых:

https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D1%81%D1%83%D0%BF%D0%BF%D0%BE%D0%B7%D0%B8%D1%86%D0%B8%D1%8F

https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B4%D0%BC%D0%B5%D0%BD%D0%B0_%D1%82%D0%B5%D0%B7%D0%B8%D1%81%D0%B0

https://cyclowiki.org/wiki/%D0%9E%D1%86%D0%B5%D0%BD%D0%BE%D1%87%D0%BD%D0%BE%D0%B5_%D1%81%D1%83%D0%B6%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5

Я, знаете ли, в разные периоды жизни по разному реагировал, когда собеседник/оппонент начинал использовать подобные приемы.

Горячился, махал руками, пытался что-то объяснять.

Сейчас я придерживаюсь следующей позиции - никогда не садитесь играть в карты с шулером.

Что это значит?

Это значит, что, если вы не обозначите свое отношение к высказанному утверждению, максимально четко и ясно, то вы примете мысленный фреймворк оппонента, а ему только это и нужно.

Например, если ваш оппонент говорит, что "А - хорошо, Б - плохо" (оценочное суждение), то вам не стоит начинать обсуждать, действительно ли A - хорошо, а Б - плохо. Если вы начали это обсуждать, то вы попались - вы приняли право вашего оппонента навязывать вам определения "хорошо" и "плохо". И на этом поле оппонент вас обязательно выиграет, потому что выигрывает тот, кто определяет, что хорошо, а что - плохо.

Поэтому, когда я вижу, что собеседник пользуется одной из таких логических уловок, у меня в диалоге случается "full stop".

Я говорю собеседнику, что он воспользовался подобным приемом (*), и предлагаю ему либо согласиться, и переформулировать мысль, или не согласиться, и доказать мне, что я ошибся, или закончить наш диалог. Потому что не надо садиться играть в карты с шулером! Не надо пытаться договориться с шулером в рамках правил, которые он вам навязывает, потому что вы автоматически проиграли. Сначала договоритесь про устраивающие вас правила.

Ну а дальше либо диалог переходит в более конструктивное русло (в случае оценочного суждения, например, вам стоит на берегу договориться о том, какие объективные критерии вы измеряете, без "хорошо" и "плохо"), либо заканчивается.

(*): да, прямо так и говорю - "это пресуппозиция", или "это оценочное суждение", или "это подмена тезиса".

Гемдев мир настолько очистился, что хорошие тутористы возвращаются с переходом на Godot!

И на этом самом годоте на недавнем геймджеме Ludum Dare я в компании хороших людей запилил небольшую игру.
В комментах все хвалят музыку и графоний (это не я делал!) и ругаются, что сложно играть (а это уже я! но делал сложнее, а получилось попроще, но всё равно ругаются)

Если кто хочет попробовать или ещё и проголосовать: https://ldjam.com/events/ludum-dare/55/last-minute-awakening

Так что не удивляйтесь, если буду писать и репостить всё больше про игры и их разработку - похоже, что настало время всё меньше страдать фигнёй, а всё больше делать что-то своё, полезное и неочень.

По мотивам этого прикола и других недавних обсуждений всплыла одна интересная, на мой взгляд, моделька.
Хочется сказать пару слов про неё, почему и где она мне кажется полезной, на примере геймдева и другого около-IT опыта.

Про саму модельку design-time vs. run-time

Простыми словами, что это:
- design-time - это когда что-то продумывают (зачем как и где это будет работать) и создают
- run-time - это когда это же что-то работает

Почему это полезно выделять как разные штуки:
- для design-time и run-time нужны отличные друг от друга силы и ресурсы, роли и много чего ещё
- design-time сильно влияет на run-time - чем лучше продумать и реализовать, тем лучше это будет работать
- на переключение между продумыванием и исполнением может уходить много сил и ресурсов, или качество одного или другого может сильно страдать, потому как ресурсов не нашлось и что-то сделано хреново. Особенно если хреново сделан design
- всё это происходит не один раз, потому как результаты работы (run-time) оцениваются и снова происходит дизайн, реализация, исполнение - можно тут вспомнить цикл Дёминга-Шухарта aka цикл PDCA: plan, do, study, act

Потому, если всё мешать в кучу, то
- или цикл не проворачивается - мы только думаем и фигачим на пути к безумию, зря ожидая отличные от прошлых результаты
- или проворачивается, но с плохо работающими кусочками, да и сами эти кусочки мы не видим, потому разом всё улучшить кажется сложна-сложна-непонятна, как результат - дорого
- плохо понятно, где же проблема - я неправильно делаю правильные вещи, или может правильно делаю неправильные вещи, или ещё какая-то фигня происходит

А если разделить, то можно:
- отслеживать отдельно - пусть не 4 стадии по PDCA, а хотя бы две
- улучшать их отдельно
- меньше тратить время на переключение и многозадачность

В результате - меньше тратить сил и иметь возможность улучшать результат.

Примеры натягивания совы модельки на глобус реальности приведу в следующем посте.

#systemyass

Перед описанием примеров применения хочу сделать пару дополнений:

- вся мощь модельки с разделением design time и run time для меня открывается при рекурсивном её применении - то есть run time для одной штуки может быть в то же время design time для другой. И тут важно эти штуки не путать и фиксировать в реальном мире, об чём, собственно, речь (привет, определение системы из Левенчука)
- это всего лишь моделька, использовать её лучше как линзу (привет, gamedev и Джесси Шелл с его линзами) - вот берём ситуацию и можно на неё вот так посмотреть, если получается фигня - бросаем линзу и дём дальше

#systemyass

Пример первый: недавно я впервые сыграл на барабанах на джем-концерте две песни

Design time для самого выступления:
- разбор песен дома
- тренировки игры на барабанах - отработка какой-никакой техники игры с нуля, до этого я только иногда держал палочки в руках
- общая репетиция с другими
- понять где это всё будет, не проебаться и дойти вовремя до места
- выяснение что там будет на сцене в плане установки, куда как врубать метроном

Run time:
- исполнение на сцене двух песен

В чём тут пригодилась моделька
- сформулировать run time для себя и что надо для подготовки - то есть для исполнения design time
- не путать само выступление и обучение мастерству играть на барабанах. Моя цель - выступить, а не идеально сыгать или освоить какую-то конкретную технику исполнения
- пока я играл первую песню - вылетели все техники и приёмы, руки стали деревянные, в голову полезли мысли, как я вторую песню то буду играть и прочая фигня, но это run time, это не про улучшение техники или игры - потому я в перерыве между песнями сбросил напряжение с рук и выбросил из головы мысли про фристроки, свободное движение палочки
- в итоге получить кучу удовольствия вместо переключения на то, где я как сыграл не так и что с этим делать - для этого можно потом выделить время
- вынести из концерта не только удовольствие, но и идеи, что над чем и как я хочу поработать, мотивацию записаться на урок к препроду, мысли, что я хотел бы сыграть в следующий раз или через N времени
- хорошо подготовиться, применяя модельку рекурсивно - run time репетиции это кусок design time выступления

Надеюсь, сова в этом примере хорошо облегает глобус, а если есть мысли, идеи, вопросы - то добро пожаловать в комментарии

Дальше в списке примеров - психотерапия, встреча по планированию в стартапе и недавний LD геймджем.

#systemyass

Прошёл Indika (https://indikathegame.com)

Коротко: хорошая короткая история с погружающим визуалом.
Там мало игры - это видео-новелла с 2-3 хорошо вписывающимися игровыми механиками (и с остальными не очень хорошо вписывающимися).

Самое впечатляющее - окружение/мир и подача истории через хорошо поставленные ролики. По ходу прохождения вспоминались произведения Сорокина, Балабанова, Шаламова, Германа-старшего, Мамлеева, Глуховского - мир показался загадочным и завораживающим. И очень родным, местами даже отечественным.

Стоит того, купить, пройти и перетерпеть некоторые игровые моменты.

#mesa #opengl #valve #zink

https://www.phoronix.com/news/NVK-Explicit-Sync-Valve

Надо сказать, что Valve системно поднимает графический стек Linux из руин, в которых он пребывал последние лет 20.

Надо сказать, что однажды в Linux было очень неплохое 2D ускорение, но, по мере усложнения аппаратной начинки, все это катилось в глюкавое и ненадежное говно, в которое вендоры иногда щедро подливали своих бинарных блобов, которые нормально работали примерно только на машинках их разработчиков, то есть, почти нигде.

Вроде, есть Intel, есть AMD, которые выкатили oss драйвера, а теперь вот и Nvidia, но починкой всего стека системно занимается именно Valve.

Не думаю, что они делают это для благотворительности, и у них есть понятный коммерческий интерес, но, в целом, их вклад сложно переоценить.

Комментарий специалиста:

Есть два закона, первый — шуточный закон Старджона ("90% всего — полное говно"), второй — какой-то закон из социологии, название которого я не помню, но он про то, что выборка людей, взятая по одному параметру, по остальным параметрам начинает повторять популяцию в целом. То есть, если бы берем всех "ученых", то внезапно оказывается, что процент идиотов там такой же, как везде, если берем всех "медиков", то процент курящих или верящих в гомеопатию или плоскую землю там такой же.

Знание этих законов освобождает от удивления, возмущения и разных прочих чувств, когда вы сталкиваетесь с чем-то подобным.

Ну и потом, это же гештальт.