AtomKrieg

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

1. Анализ формата save-файла и извлечение необходимых данных из него. Часто это оказывается единственно возможный путь, не смотря на кажущееся неудобство такого подхода.
   
2. Вычисление статических адресов в адресном пространстве процесса, по которым находятся переменные, в которых хранятся какие-то важные игровые параметры. Для этого давно существуют такие автоматизированные инструменты как ArtMoney. Но против современных игр все это практически бесполезно, так как все структуры данных хранятся в динамической памяти.
   
3. Гонять игру под отладчиком, выявлять функции (точки входов в них) которые вызываются на определенные игровые события, анализировать параметры этих функций, искать среди них переменные, отвечающие за какие-то значимые игровые параметры. Потом писать патч к игре, в котором перехватывать эти функции и сохранять передаваемые параметру куда-нибудь, откуда их можно легко получить снаружи.
   

Не совсем понимаю зачем, но чтобы вызывать функции в одну строку, достаточно в функции в конце возвращать self.

class S():
    kk = 0
    def m(self):
        kk+=1
        return self
    
    def p(self):
        print(self.kk)
        return self

s = S().m().m().m().p().m().m().p()

выведет "3" и "5"

Пакеты Джавы и сборки Дотнета - это про модули в терминах крупной структуры приложения, они тут не при чем.
Речь идет о модулях на уровне программного кода.
Хотите примерно понять как это будет выглядеть - посмотрите, например, на юниты в Паскале. Это примерно и есть то, что хотят получить в конечном счёте - возможность по-человечески, на уровне языка, объявлять интерфейсы модулей, подключать их друг к другу, следить за зависимостями между модулями (разве что модули C++ вроде как не привязываются к единице компиляции, в отличие от юнитов Паскаля).
Сейчас в C++ это достигается большим хаком на уровне препроцессора (а не компилятора языка), называющимся include-файлы. Этот механизм, основанный на правиле "много объявлений, одно определение", унаследован из Си, и по сути представляет собой замену отсутствующей возможности передавать метаданные от одной единицы компиляции к другой при сборке проекта. С помощью инклудов вы напихиваете в один файл ВСЕ, что может потребоваться компилятору. По факту выливается в то, что бОльшая часть единицы компиляции после обработки препроцессором - это содержимое инклуд-файлов. И всё это обрабатывается компилятором каждый раз заново (в каждой единице компиляции). В Си это еще куда ни шло, но в плюсах, где многие библиотеки содержат тяжелый шаблонный код, это становится совсем печальным. Помимо этого, сама работа с инклудами - это непростая практика, и если следовать ей неверно, особенно новичкам, они могут получить от компилятора удивительнейшие ошибки. За примером далеко ходить не надо - попробуйте в большом проекте не ставить защиту от множественного инклуда.
Вся эта препроцессорная магия красоты и прозрачности языку не добавляет. Пока в других языках пишут "package foobar" и "import foobar", мы пишем "#pragma once" или даже "#ifndef FOOBAR_H ...". Уже грустно как-то становится.

Вышесказанное в одно предложение: модули хотят сделать настоящими, вместо имитации средствами препроцессора.

Вроде то, что вам нужно - opencv.org
docs.opencv.org/3.0-beta/doc/py_tutorials/py_tutor...

Видимо компилируете 32битный бинарник, был бы 64битный, показало бы 2 элемента. Потому что sizeof(my_array) в вашем случае вернет не размер массива, а размер указателя на массив, а он всегда равен sizeof(int) в вашем случае. Размер надо прокидывать снаружи. Компилятор не таскает размер массива вместе с массивом.

На питоне часто пишут какие то мелкие тулзы для внутренних нужд компании. Возможно именно это и есть причина. А вообще - вы можете прийти на собеседование и спросить - зачем им питон :-)

Вот так делать - это нормально?

Вполне

И что в таком случае возвращается, указатель на функцию или сама функция?

Функциональный объект. Лямбда — не функция, она может быть приведена к указателю на функцию в некоторых случаях.

Если возвращается указатель, то где хранится сама функция, в куче или стеке?

«Функция» лямбды хранится там же, где и остальной код. На лету ничего не собирается и не компилируется. Лямбда это синтаксический сахар для объявления класса с перегруженым оператором вызова функции.

И еще один вопрос, по этой же теме:
Это сокращенная запись вот такой конструкции:
Или что то другое?

lambda имеет уникальный тип. Это не функция (но может быть приведена к ней в данном случае).

А в чём проблема? Длины массивов известны, берём полусумму длин и сдвигаемся параллельно по обоим массивам на эту величину, аналогично сортировке слиянием.
Ватиант на JS, то что с ходу получилось.

arr1 = [1, 3, 5, 7];
arr2 = [2, 6, 10];
p1 = arr1.length;
p2 = arr2.length;
n = p1+p2;
if (n == 0)
  n--;
med = 0;
p1--;
p2--;
while (0 < n) {
  if (p2 < 0 || (p1 >= 0 && arr1[p1] > arr2[p2]))
    med = arr1[p1--];
  else
    med = arr2[p2--];
  n -= 2;
}
if (0 == n) {
  if (p2 < 0 || (p1 >= 0 && arr1[p1] > arr2[p2]))
    med = med+arr1[p1];
  else
    med = med+arr2[p2];
  med /= 2;
}
console.log(med);

P.S. Если предварительно найти область пересечения массивов, то можно уменьшить объём просматриваемых данных.