dollar

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

Строго говоря, механика и интерфейс игры могут быть описаны на любом языке, в том числе на скриптовом. Лично я предпочитаю Lua, как самый простой язык из довольно мощных. Он даже проще Питона, хотя и беднее по встроенным возможностям из коробки. Главный плюс в том, что логика игры может быть легко модифицирована обычными игроками, а это заранее даёт игре второе дыхание.

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

Можно, если на игровом сервере присутствует несовершенство, которое можно эксплуатировать для быстрого подключения к серверу. Сложность в том, чтобы найти эту уязвимость и понять её. И ещё сложность в том, чтобы знать C++. Если две эти сложности преодолены, то не вижу проблемы в том, чтобы написать свой fastconnect на языке C++.

Почему? Потому что мало кому нужна такая визуализация. Большинство устраивает, что есть локальная область видимости переменных, и считает, что лишняя приставка усложняет чтение. И крайне мало кому нужно конвертировать свой JS код на другие языки.

Но вы можете так делать для своего кода, если нужно и удобно.

Отступы.

Точнее, отступы в цепочке методов.

Если и есть какое-то особое название, то оно не популярно. И употребив его, вы рискуете быть не понятым. К примеру, сказав слово "отступы", сразу понятно, о чем речь. А вот выражение "цепочка методов", хоть и практически однозначно, но всё же заставляет задуматься, потому что редко используется. Можно же сказать менее однозначно: "цепочка вызовов", "цепочка функций", "последовательность вызовов" и т.п., но эти выражения тоже используются с пояснениями, что они значат. Поэтому не стоит искать правильное название, лучше подобрать наиболее понятное для тех, кому вы хотите донести суть вашей мысли, и раскрыть его другими словами.

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

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

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

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

Возможно, вам стоит подучить архитектуру компьютера, в частности процессор x86 и память, и как они связаны. Наиболее близкий язык, чтобы во всё это окунуться - ассемблер, очевидно. Если интересует именно скорость языка (которая, к слову, для многих задач не критична), то нужно смотреть высокоскоростные компилируемые языки - С, С++, Rust, D, Go, а также близкие к ним по скорости через VM - C#, Java (Kotlin). Узкоспециализированные типа Swift можно не рассматривать, если они вам не нужны для решения задач. Но даже в скриптовых языках (JavaScript, PHP) сейчас очень хорошо со скоростью. Посмотрите также, что такое JIT, тоже удивитесь, если не слышали ранее.

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

В английском языке существительные в начале превращаются в прилагательные, а в конце - существительное, к которому они относятся.
Сравните: "stone wall" (каменная стена) и "wall stone" (камень из стены).

То есть первым делом нужно определиться с главным существительным, то есть ЧТО имеется в виду. Если это имя, то название переменной должно оканчиваться на _name (или Name в зависимости от стиля).

Далее, если не придираться к правилам, то последовательность прилагательных лучше делать так: чем важнее, тем ближе к существительному.
Шаг первый: product_name
Шаг второй: homepage_product_name (при этом вам должно быть очевидно, что не home_page)

Далее, ничего лишнего быть не должно, и должно максимально точно отражать суть. Например, настройка, говорящая о том, что уведомления можно посылать только если приложение неактивно.
Не правильно: notify_if_inactive (вообще не понятно, не логично)
Правильно: is_notify_if_inactive_only
Приставка is_ в данном случае является соглашением в нашей команде, указывающем, что это булева переменная, можно также юзать b_ например для той же цели. Или, скажем, если это константа или меняется очень редко, можно записать капсом или добавить приставку c_

Вообще дальше уже начинаются тонкости и вкусовщина. Основные принципы изложены выше - это четкий порядок построения и соответствие сути.

Вообще JavaScript. Как вариант - расширение для браузера.

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