rPman

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

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

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

Иногда можно анализировать сетевой трафик, если он нешифрованный.

Не нужно делать интерфейс только потому что 'все так делают'.

Исходить нужно исключительно из задачи! Делать нужно ровно столько сколько нужно и не больше не меньше.

p.s. Когда то я работал активно с данными, конечно экселя могло бы быть достаточно но он неудобный и медленный
Обычно нужен для конвертера следующий UI (писался давно, не очень использовался и затерялся):
* Настройка источника данных (у вас это кнопка/поле - место откуда брать excel источник, плюс к примеру имя/номер листа)
Показать начальное содержимое листа при выборе, минимальную статистику (количество строк, колонок и т.п.)
* Список необходимых колонок с указанием, какие колонки чем являются
При выборе колонки источника показывать список вариантов его значений (не обязательно все, первые десятки, но бегло дает представление о значении поля)
* Фильтры (пропустить пустые строки, убрать дубликаты и прочее прочее) - не перебарщивай, очень редко задачи повторяются, все объять невозможно, можно предложить поле для ввода кода (использовать в eval), если источник база данных - можно запилить какой то минимальный конструктор sql (без ui, хотя список таблиц и название колонок в базе уже круто, плюс поиск по подстроке по данным во всех таблицах - удобная вещь когда ковыряешь чужую базу, лучше это делать в специализированных программах, помню пользовался dbforge studio community version)
* настройка назначения вывода данных (имя файла)
* настройка типа данных в файле вывода (выбор из списка захардкоженных в программу, если актуально само собой)

Еще момент - интерфейс должен быть исключительно интерфейсом к консольной программе, генерируя для нее строку/файлы настроек, чтобы можно было их использовать к примеру для автоматических регулярных запусков без запуска интерфейса (я генерирую в таких случаях батник с запуском программы с нужными ключами)

Дико интересный вопрос, как вообще в анализе данных с этим справляются?

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

Еще вариант, что такое усреднение по суткам? это значит сложить значения год назад, два назад, три назад... вот и берите тот день, который был год назад, воспользовавшись получается данными в один и тот же день в прошлом для вычисления среднего в разные дни (так можно делать для min/max/average методов, а вот складывать нельзя).

Решение в лоб, так как признаков у вас мало, ищите по отдельности для всех комбинаций присутствующих признаков (т.е грубо говоря если например у вас 6 признаков и в данных могут отсутствовать одновременно по 1 и 2 признака, то у делите выборку на 20 частей по всем возможным комбинациям пропущенных признаков и для каждой ищите свой классификатор).

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

1. необходимо любым доступным способом отлавливать появление новых записей в базе (так или иначе это можно сделать либо в приложении, которое пополняет базу, либо тригером, совершающим действие 'снаружи', если ничего удачного БД не позволяет… периодически (в 2 раза чаще чем самый короткий интервал) делать максимально простой запрос — например текущее значение сиквенса в табличке
1. пишется демон (1 процесс), который должен ловить событие от появления записи в БД и вычислять время срабатывания ближайшего таймера (простейший запрос к табличке, сортировка по времени срабатывания таймера — лимит 1) и ждать либо срабатывания таймера либо следующего события добавления записи

Описанное вами — это развитие реляционной модели в сетевую… в mysql как я знаю средств для этого нет, в postgresql есть поддержка массивов, только производительность не ля всех случаев оптимальна.

Ваша задача лучше всего решается все таки сериализацией. Проблема обновления данных при расширении функционала не на столько критична чтобы только на основании этого отказываться от сериализации.

Так же не стоит закрывать глаза штатную реализацию списков второй таблицей M-1.

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