GavriKos

Я советую забыть для начала о ChatGPT и прочитать пару постов (или посомотреть видео) "мой первый workflow".
Если коротко, Self-Hosted Runner обычно не нужен.
Чтобы запуститься на линукс, пишем

runs-on: ubuntu-latest

базовый синтаксис в основах вообще почти один. но ментальность другая. мелкий проект куда ни шло, если веб и/или службы... работа с бд..
за 2-3 дня вряд ли..
был у меня случай, переводил проект что то порядка 1500 строк с c++ на c#, вышло примерно в 2 раза меньше строк, и работало быстрее (плюсовый явно многими авторами довольно криво дописывался)... однако способность прочитать, и перепроверить в дебагере, не дала мне способности писать на плюсах )))

ps на языке, надо в некотором смысле "думать"... плюсовый вектор, и лист шарпа, похожи только на первый взгляд..
в шарпе есть перегрузки, в тч операторов, но не так популярны (я лично тащусь, но логика уже другая)...
... в общем все зависит от масштабов и сложности проекта..
... сходство базового синтаксиса, как раз может сыграть коварную роль
но кто не рискует ... ;)))

Одновременно и просто и сложно, зависит от "глубины погружения в тему"
Для различных авто немного по разному, но принцип один и тот же, по ОБД данные доступны через запросы к соответствующему модулю (MRM,ABS,ESP ....) (думаю для разных машин по разному и с различной точностью, количеством инфо) скорость поворота руля и угол поворота (если память не изменяет с точностью до десятых долей) скорость вращения каждого колеса тоже с точностью до десятой доли км/ч. Но тут встает момент, что некоторые модули ABS при таких запросах становится в диагностический режим а свыше 30-50 км/ч выходят из него и перестают отвечать на подобные запросы. Но это не отменяет возможности подслушивать эти сообщения по CAN, например в приборку прилетает постоянно скорость. Но и тут от модели авто зависит, где-то это просто скорость, а где-то 4 значения по каждому колесу.
И 2й вариант подслушивать эти сообщения на шине, когда блоки общаются между собой. И опять ньюанс, на разных машинах по разному, но например высокоскоростная шина моторного (мотор коробка абс) не флудит этим трафиком в ОБД, а на некоторых машинах наоборот все слышно по ОБД
По частоте запросов точно не скажу, тоже вариативно, но минимум 1-2 запроса в секунду должно проходить, если запрашивать у блока, а если подслушивать, тот тут все от блока зависит. Вы же понимаете, что для своих целей внутри ABS получает данные напрямую с датчика, и в состоянии определить пропущенный сегмент на задающем диске а частота опроса в милисекндундах.

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

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

1. Каждое открытие инвентаря это запрос к БД (т.е. при стоянии на месте и щелкая кнопку, мы будем нагружать БД запросами)?

Нет. Данные загружаются в оперативку при логине персонажа. Изменения также касаются оперативки. В базу скидывается при логауте. Ну еще периодически для синхронизации.

2. Каждое выпадение золота в мир это новая запись в общую таблицу мира, что в такой-то точке есть объект "золото"?

Да. есть объект "предмет". Есть структура "список предметов", скорее всего двухсторонний список. Он обновляется, в него добавляется, из него извлекается. Предметы в мире не записываются в базу вообще (если вы помните, при ребуте все что не в чьем-то инвентаре, пропадает. Не так уж много оперативки это занимает. Просто посчитайте.
Максимальный онлайн на шарде - 5000 игроков.
Объект - ну учитывая тип предмета, уникальный айди, разные параметры типа заточки, владельца, место, и так далее - 10-20 байт более чем достаточно. Ну давайте 50 байт возьмем, хотя на деле я уже не помню сколько там было, явно меньше.
50 байт * 5000 игроков и скажем 100 предметом у каждого - получим примерно 23 мегабайта.
Добавить клановые хроанилища. ну 30 мегабайт. Много это оперативки на сегодня? По-моему вообще разговор ни о чем.

3. Что происходит после того, когда золото было поднято, эта запись превращается в null?

Объект удаляется из списка.

4. При интенсивном обороте этих действий, как реализуется такая таблица, чтобы она не переполнялась за неделю?

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

5. Для игр подходит любая БД (например Postgres) или есть определенный тип игровых БД?

Любая. В Lineage2 использовался MSSQL, в самописном народном java эмуляторе использовался mysql

Я больше десяти лет участвую в процессе найма и уже давно перестал смотреть эти списки "знаю HTML на 88%, а javascript на 42%". Помимо того, что эти проценты абсолютно бессмысленны и высосаны из пальца, действительно, обычно люди пишут туда всё, мимо чего проходили.

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

Никак. Либо ты лучом проверяешь каждую дробинку, либо используешь другой каст, например SphereCast

Технических проблем не будет при любом сочетании. Можно поставить рядом с 4к монитором на 160hz старый 1366х768@60hz и все будет прекрасно работать.
Минусы такого решения:
- не всегда удобное перемещение мышки между мониторами
- разный масштаб окон
- разная цветопередача
Для кого-то это всё не существенно, а кого-то может сильно раздражать.

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