[Dev] Steam-Lite

[andreil]

О программе
Разработка данной программы ведется с целью изучения работы сети Steam'а и клиента в частности, в ходе которого "рождаются" программные модули, позволяющие как минимум эмулировать клиент данной сети (в идеале - копировать с некоторыми модификациями).
Основные возможности программы (предполагаемые, в порядке их внедрения):

• Управление файлами игр на уровне CFToolBox и выше (на данный момент почти завершено редактирование содержимого файлов игр с полным принятием таких файлов Steam'ом);
• Запуск игр, инструментов и использование медиа-приложений на уровне, максимально приближенном к оригинальному проекту ( на начальном этапе - на уровне обыкновенной пиратки);
• Обмен контентом приложений между пользователями посредством PEER-TO-PEER-сети (аналогично Torrent'у).

Так же будут доступны расширенные функции, но данное направление еще четко не сформировалось, поэтому ничего конкретного писать не буду.

---

Структура программы
На данный момент основная концепция программы основательно (но еще не окончательно) проработана и постепенно претворяется в жизнь. Вся программа будет состоять из набора модулей (плагинов), отвечающих за реализацию конкретного направления функционирования программы. Один плагин может содержать как один, так и несколько модулей (например, вместе с модулем, реализующим общую работу с файлами - INTERFACE_FILE_FORMATS - будут находится модули реализации работы с некоторыми базовыми типами файлов - GCF/NCF, VPK, PAK и т.п.). Каждый модуль представляет собой обыкновенный класс с виртуальными методами, поэтому их написание возможно на любом языке с поддержкой вызовов методов Сишных классов (на .NET придется сильно извращаться, но то все возможно).

---

Сейчас выделены следующие модули:

1. INTERFACE_CORE - список остальных интерфейсов;
2. INTERFACE_LOG - ведение лога;
3. INTERFACE_UTILS - интерфейс с различными вспомогательными функциями;
4. INTERFACE_SETTINGS - доступ к настройкам;
5. INTERFACE_TRANSLATION - реализация многоязычной поддержки;
6. INTERFACE_APPLICATION_LIST - реализация работы со списком приложений (игры, инструменты, медиа, файлы кэша);
7. INTERFACE_WORK_LIST - реализация работы с заданиями (добавление, удаление, приостановка и т.п.);
8. INTERFACE_UI - реализация пользовательского интерфейса;
9. INTERFACE_NETWORK - реализация сетевых протоколов;
10. INTERFACE_P2P - реализация p2p сети;
11. INTERFACE_GAME_CONVERTER - конвертирование игр;
12. INTERFACE_FILE_FORMATS - универсальный класс для работы с файлами;
13. INTERFACE_FILE_FORMAT - реализация работы с конкретным форматом файлов (могут различаться дополнительными функциями после основных);
14. INTERFACE_FILE - реализация работы с конкретным файлом (могут различаться дополнительными функциями после основных);
15. INTERFACE_APPLICATION - общий класс для работы с приложениями;
16. INTERFACE_APP - промежуточный клас (набор методов), общий для приложений (не для файлов кэша!);
17. INTERFACE_CACHE - работа с отдельным файлом кэша;
18. INTERFACE_GAME - работа с отдельной игрой;
19. INTERFACE_MEDIA - работа с отдельным медиа-приложением
20. INTERFACE_TOOLS - работа с отдельным инструментом;

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

---

Классы INTERFACE_GAME, INTERFACE_MEDIA и INTERFACE_TOOLS хранятся в списке внутри класса INTERFACE_APPLICATION_LIST и приведены к типу INTERFACE_APP для упрощения взаимодействия с ними.

---

По данной ссылке можно будет просмотреть самую свежую версию заголовочного файла с описанием классов (на Delphi).

Добавлено спустя 5 минут 57 секунд:
По опросу (что бы не возникало лишних вопросов) - данная структура подразумевает, что файл кэша будет находиться внутри архива (например, ZIP) и его использование будет происходить без распаковки, напрямую из архива. Над данной возможностью задумался, поскольку многие файлы кэша более чем отлично ужимаются и это позволит съэкономить значительные объемы дискового пространства. Естественно, такое использование файлов налагает некоторые ограничения (файл будет открываться только на чтение и к нему невозможно будет применить обновление).

[MOZGIII]

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

А по структуре в целом - очень неплохо получилось, продуманно так. Правда я бы сразу зареквестировал ещё и интерфейс для подгрузки пользовательских плагинов (INTERFACE_PLUGIN например).

И да, можно код куда-нибудь на github разместить, или на bitbucket хотя-бы. А то вот ксмовский SVN сейчас лежит (у меня по крайней мере, или я стучусь не туда, хотя вроде туда...), да и изменения на нём трекить неудобно. А так было бы и за ходом разработки смотреть удобно, и помогать, в случае чего, тоже.

PS: недавно научился поднимать локальный [url=htp://gitorious.org/]Gitorious[/url] - отличная штука, могу, если надо, помочь с поднятием этой вещицы для проекта (или для всего ксм).

[andreil]

MOZGIII
Насчет архивов - это пока только затея, поэтому сильно не обдумывалась пока.
По плагинам - еще много буду дополнять пом мере написания основных модулей, поскольку то, что я пока выложил - всего лишь наброски, сделанные без написания кода ;) Сейчас уже начал реализовывать GUI и сразу наткнулся на несколько граблей (все они, правда, связаны с особенностями VCL, поэтому никак их не обойти :( - например, окно может создаваться только в рамках основного потока программы, а я хотел весь UI выделить в отдельный поток - в главном потоке крутился бы планировщик заданий).
SVN у себя поднимать не буду - в сети я вообще сейчас редко бываю :( А залить куда-либо могу.


PS: Надо бы не забыть написать комментов к коду поболее, что бы всем все понятно было...
PPS: Первую версию UI хотел сделать консольным %) - задолбалось писать вывод инфы и вернулся к VCL

[MOZGIII]

andreil
Используй git при разработке, он и без сервера отлично работает (совсем не как SVN в этом плане). Тогда и залить можно на Github (ну, правда тогда код будет лежать в паблике, если хочется закрытое хранилище - то лучше поднять своё, но на первое время сойдёт и BitBucket - там ограничение для закрытых репо - максимум 5 акков могут в репо коммитить). Если возникнут сложности с гитом - пиши в лс или асю, помогу %)

А по поводу VCL и GUI - может быть вообще сделать UI отдельным процессом + взаимодействие через сеть? То-есть INTERFACE_UI будет выступать сервером, а ещё какое-то приложение - консольное, или графическое, или веб - клиентом. Это будет хороший стиль, хе-хе %)

[NiGHt-LEshiY]

через сеть

Кстати, в Windows есть пайпы или что-то такое? Менее затратно, чем через сеть..

[x_000]

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

[MOZGIII]

Я работал с пайпами под виндой. Ну что можно сказать... "Не очень".

NiGHt-LEshiY
По поводу затратности - почему?

x_000
Под Windows пайпы (именнованные) косят под Unix domain socket. Однако, и в пайтоне, и в MySQL например, и много где ещё используется сеть вместо пайпов (хотя в *nix тот же MySQL спокойно пользует домэйн-сокеты). Я думаю всё потому, что в Windows не очень хорошо реализована архитектура пайпов (ну, по крайней мере когда я с ними работал - года 2 назад - мне там что-то не нравилось, не помню уже что).

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

Добавлено спустя 41 минуту 5 секунд:
Кстати, плюсы в сторону такой (клиент-серверной) архитектуры GUI - cам GUI можно писать отдельно от всего ядра (даже в отдельным репо), его можно писать не только на дельфи (Qt, Gtk, Web), их можно сделать несколько (бывает, окошко, например, не понравилось - написал свой), увеличит портируемость - перенести основной код на никсы тогда будет вообще просто, увеличит стабильность - при вылете GUI само приложение не крашится. Да и сама разработка от этого не сильно усложнится - если выделять гуи в отдельный интерфейс, он будет итак уже достаточно отделён от остального кода программы, что-бы сделать реализацию взаимодействия по модели клиент-сервер простой. Да и основную программу тада можно будет запускать как сервис, а гуи - только когда понадобится (это, конечно, на любителя, но некоторые, особо нуждающиеся в свободной операте, так делают). Вообщем, в описанную концепцию такая реализация GUI впишется очень хорошо.

[NiGHt-LEshiY]

По поводу затратности - почему?

Это как, например, небуферизованная запись в файл по одному байту. Или стэк не в RAM, а на диске. Лишний оверхэд.

[MOZGIII]

Это как, например, небуферизованная запись в файл по одному байту. Или стэк не в RAM, а на диске. Лишний оверхэд.

Откуда инфа? Не вижу связи с небуферизованным чтением/записью, потому как и сеть и пайпы используют буфер, да и с диском не работают они вообще. Кстати, на современных компах (им ввиду и железо и ос) стек можно без проблем и на харде держать (формально, реально у жёсткого диска есть свой буфер, по скорости не уступающей операте, мегов, эдак, на 60, так что стек на диске живёт достаточно себе неплохо - если конечно уметь его правильно готовить).
Чем конкретно (на чём) пайп быстрее сокета? На сколько? Есть ли смысл заморачиваться ради такого прироста скорости, или же он не существенен для сабжа?

[NiGHt-LEshiY]

MOZGIII
О б-же, я привел пример.

Чем конкретно (на чём) пайп быстрее сокета?

Скоростью, чем же ещё можно быть быстрее?

На сколько?

Замеры не производились.

[andreil]

А по поводу VCL и GUI - может быть вообще сделать UI отдельным процессом + взаимодействие через сеть? То-есть INTERFACE_UI будет выступать сервером, а ещё какое-то приложение - консольное, или графическое, или веб - клиентом. Это будет хороший стиль, хе-хе %)

Если юзать VCL, то никак - конструктор главного окна, как и его деструктор, должны вызываться из главного потока и все формы будут выполняться в его рамках. Я это обошел так - добавил в WorksList задание загрузки программы и после этого показал форму. Все задания выполняются в отдельных потоках, а при запуске данного задания предусмотрена пауза на 0,5 сек для того, что бы 100% успело показаться как главное окно, так и окно загрузки (взял с запасом для того, что бы успели прогрузиться все надписи из языкового файла).

Кстати, плюсы в сторону такой (клиент-серверной) архитектуры GUI - cам GUI можно писать отдельно от всего ядра (даже в отдельным репо), его можно писать не только на дельфи (Qt, Gtk, Web)

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

их можно сделать несколько (бывает, окошко, например, не понравилось - написал свой)

Это планировалось изначально :crazy: Пользователь сможет "на лету" переключать интерфейс программы на другой (предположительно, это будет выполнено в виде скинов - каждый модуль интерфейса будет лежать в отдельном каталоге со своими ресурсами).

, увеличит портируемость - перенести основной код на никсы тогда будет вообще просто, увеличит стабильность - при вылете GUI само приложение не крашится.

Для реализации данного пункта (как и предыдущего) придется несколько усложнить работу с интерфейсом и всю работу с ним производить по следующему принципу:

Код: Выделить всё

if (Core.UI <> nil) then
  Core.UI.OnLoadingStart();

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

[MOZGIII]

andreil
Я имел ввиду именно отдельный процесс, а не отдельный поток, т.е. основная программа (сабж) будет выполняться в системе в виде демона (сервиса), а также будет ещё одна программа отдельная, которая будет к ней GUI, подсоединяться будет по сети (ну, к 127.0.0.1). То-есть в результате мы получим полное отделение GUI от программы, не на уровне скинов (это уже не модно - устаревший подход), а на уровне движка GUI. Ну и, соответственно, в системе у пользователя оба процесса будут выполняться независимо, что позволит в GUI спокойно показывать окна в главном потоке.
Взаимодействие по сети можно настроить с использованием протокола WebSocket (да, я именно о том, новом протоколе из семейства HTTP) - тогда можно будет писать клиент на HTML+JS без отдельного бекенда, да и сам по себе протокол весьма прост и удобен. Ещё его плюс - нативная поддержка HTTP проксями (современными). Для создания структуры пакета можно использовать сериализацию в JSON.
Я уже писал пару проектов с такой архитектурой - получается очень классно (потому и советую)!

NiGHt-LEshiY
Во первых, скорости бывают разные, в данном случае: чтения/записи/синхронизации. Да, это КЕП, что быстрее можно быть только в какой-то скорости, но я спросил именно "в какой конкретно". Ответ подразумевается такой например: "На записи в пайп данных, больших по объёму чем размер буфера".
Во вторых, для того, что-бы делать такие заявления - нужно сначала провести бенчмаки.
В третьих, примеры совсем не из той оперы, я уже писал выше по какой причине. Коротко: при чём тут диск, если и сокеты и пайпы есть суть способы межпроцессорного взаимодействия, и выполняются они целиком в памяти. Да и буфер используется и в сокетах и пайпах, так что в этом (буферизация) разницы нет.
Пайпы в виндах релизованя как лысый чёрт, потому никому их использовать не советую. Всё потому, что ещё в те далёкие времена, когда мелкомягкие только изобрели NT, и у них было в нём всё плохо (то-есть в том из чего они его делали всё было терпимо, но они всё сломали), народу уже нужна была сеть, сокеты и всё такое, и их стали допиливать напильником и выпрямлять. На пайпы тогда тратили времени, мягко говоря, поменьше, поэтому сетевая часть винды получилась получше оптимизированной, чем пайпы. Печалит, что исходнички не почитать...

Добавлено спустя 1 час 12 минут 59 секунд:
andreil
Так, кстати, будет намного меньше гемора с переподключением модулей на лету - для GUI достаточно будет перезапуска самого GUI, а для демона - а нужно ли оно вообще в таком случае? К тому-же так можно абстрагироваться на только от конкретного движка GUI, но и от отдельных деталей в его "планировке" - например, меню настроек можно передавать в виде подобия Valve-овских res файлов - то-есть в виде абстрактного деерева.
Например (в синтаксисе JSON):

Код: Выделить всё

{

  "setting_menu": {
    "title": "Настройки",
    "pages": {

      "main": {
        "title": "Основные настройки",
        "fields": {
            "server_address": {
              "name": "Адрес главного сервера системы (пример)",
              "type": "text", // или например: number, positive_number, selection
              "value": "steam-lite.ru"
            },
            "steamapps_dir": {
              "name": "Директория для хранения игр",
              "type": "file" // нужно будет реализовать браузер файлов, показывающий файлы на демоне, если управление идёт не локально (это легко)
              "value": "E:/Games/Steam-Lite/steamapps"
            }
          }   
        }
      }

    }
  }

}

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

[Pr0Ger]

Я имел ввиду именно отдельный процесс, а не отдельный поток, т.е. основная программа (сабж) будет выполняться в системе в виде демона (сервиса), а также будет ещё одна программа отдельная, которая будет к ней GUI, подсоединяться будет по сети (ну, к 127.0.0.1).

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

Взаимодействие по сети можно настроить с использованием протокола WebSocket

WebSocket для межпроцессного взаимодействия? это даже хуже чем просто сети
чем сложнее система, тем больше там мест для ошибок
чую ты прочитал про MVC, но не прочитал про KISS
подход с разделением отображения и обработки конечно правильный, но зачем переусложнять

тогда можно будет писать клиент на HTML+JS

да, зачем программа весом в 5 Мб максимум, давайте лучше напишем на Qt, где один только QtWebKit.dll будет весить 12 Мб

намного меньше гемора с переподключением модулей на лету - для GUI достаточно будет перезапуска самого GUI

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

[MOZGIII]

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

Именно об этом я и думаю. Это очень удобно реализовано у Transmission (или uTorrent).

WebSocket для межпроцессного взаимодействия? это даже хуже чем просто сети
чем сложнее система, тем больше там мест для ошибок
чую ты прочитал про MVC, но не прочитал про KISS
подход с разделением отображения и обработки конечно правильный, но зачем переусложнять

При чём тут MVC? MVC и WebSocket - вещи структурно несвязанные. Похоже, что это ты рассматриваешь WebSocket только как дополнение к MVC - но не стоит этого делать. WebSocket, как проткол, имеет очевидные преимущества - самое главное из которых - проксируемость стандартными HTTP проксями. Про MVC хочу отдельно сказать, что тут этот паттерн неприменим - он вообще плохо применим везде, где есть событийная модель.
По воду KISS - а что не соответстует этому принципу? WebSocket - предельно простой протокол, с его реализацией (включая всякие хендшейки), справиться даже ребёнок. Более удобный протокол и придумать нельзя, тем более, что содержимое пакетов может быть любым. Я обычно использую JSON внутри - и получается лёгкий, простой в разработке и отладке, текстовый протокол. Почему нужно делать именно межпроцессорное взаимодействие и заморачиваться с сетью? Я это всё уже описывал выше.

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

Когда я говорю геморрой - я не имею ввиду "перезапуск на пол секунды дольше". Как я понимаю, то, что andreil планирует сделать с этим сейчас - держать GUI на VCL в одном процессе с программой, и при этом использовать несколько потоков. То-есть, для перезагрузки интерфейса юи придётся придумывать и реализовывать хитрозакрученный алгоритм перезагрузки форм, выполняющихся к тому-же и не в главном потоке. Отлаживать и писать такое - это сущщий ад. К тому-же сам VCL такое плохо переносит, поэтому, могу предположить что на этом этапе будет огроомная пробуксовка. То, что сделано сейчас - ожидание в 0.5 сек - оччень грязный хак, такое делать вообще не стоит, так как это - нестабильно. Я думаю, что тот кто со мной в этом вопросе не согласен просто почти ничего не понимает, что там реально происходит, и как проходит синхронизация потоков.
Кроме того, если уж есть желание абстрагировать код от GUI - то нужно это делать. И делать реально хорошо, иначе не имеет смысла (особенно в дельфях - там есть родной VCL, который, если не париться по вопросам отделения кода, становится предельно простым для программиста, но если наоборот - лучше уж совсем их отделять).
Итак, ещё раз, тут дело даже не в скорости работы кода, а в скорости и сложности разработки, и возможностях допустить ошибку. При подходе с реализацией через сеть - проблем существенно меньше.

Добавлено спустя 26 минут 28 секунд:

да, зачем программа весом в 5 Мб максимум, давайте лучше напишем на Qt, где один только QtWebKit.dll будет весить 12 Мб

Помоему, лучше не накидываться на вес Qt. Это уведёт нас от темы. Идея не в том, что нужно отказаться от VCL в сторону какого-то другого движка. Совсем не в том. Идея в том, что-бы предоставить возможность использования любого движка для написания GUI. Лично я считаю, что рационально будет и GUI писать на Delphi VCL, но соединять с демоном посредством сокетов. Хотя и против Qt я ничего не имею, и против Gtk, и даже против WPF тоже. И, темболее, против веб-интерфейсов с бекендами и, что вполне возможно реализовать при использовании веб-сокетов, без-бекендовых веб-интерфейсов. Вот, кастати, и примеров набралось - какие GUI можно ещё сделать, используя указанную архитектуру.
Чем плохо на самом раннем этапе разработки позаботиться о:
1. независимости ядра от крашей GUI;
2. о возможности достаточно ненапряжно написать другой GUI;
3. о возможности управлять приложением по сети (там всё-таки большие объёмы инфы грузиться будут, не плохо было бы);
4. об отсутствии необходимости проводить время за отладкой багов, возникающих из потоков VCL не в том месте (а они, иначе, будут);
5. о возможности поделить работу над проектом на 2 команды (если уж мы толпой соберёмся в помощь andreil'у).

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

Добавлено спустя 35 минут 47 секунд:
andreil

Если юзать VCL, то никак - конструктор главного окна, как и его деструктор, должны вызываться из главного потока и все формы будут выполняться в его рамках. Я это обошел так - добавил в WorksList задание загрузки программы и после этого показал форму. Все задания выполняются в отдельных потоках, а при запуске данного задания предусмотрена пауза на 0,5 сек для того, что бы 100% успело показаться как главное окно, так и окно загрузки (взял с запасом для того, что бы успели прогрузиться все надписи из языкового файла).

Так возникает Race Condition, сложновато будет наладить. На разных машинах может выполняться очень по-разному, где-то может нехватать, там будут краши. Нужно использовать семафоры. А вообще - лучше так не делать (бедный VCL же ничего не сделал, за что его так %) ).

[Pr0Ger]

Это очень удобно реализовано у Transmission (или uTorrent).

да, только сфера применения то различная
Transmission стоит у меня дома на сервачке, из универа я подключаюсь нативным клиентом и управляю
здесь же совсем другой случай, Steam по сути лаунчер, с некоторыми дополнительными функциями, и возможность разнесения интерфейса и логики на физически разные машины не нужна
да, данные можно вынести, чтобы например реализовать схему с хранением кеша на домашнем сервере, а запуск с десктопа/ноутбука

Похоже, что это ты рассматриваешь WebSocket только как дополнение к MVC - но не стоит этого делать.

все прекрасно понимаю, что использовать WebSocket, который надстройка над HTTP, который в свою очередь надстройка над TCP ради межпроцессного взаимодействия в пределах одной машины как то слишком, не кажется?
и да, я рассматриваю WebSocket лишь как протокол двустороннего обмена между сервером и веб-браузером

По воду KISS - а что не соответстует этому принципу? WebSocket - предельно простой протокол

к тому, что зачем он тут нужно, когда можно сделать без него, и значительно проще

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

ты просто не умеешь готовить
MVC говорит лишь о том, что весь код можно поделить на три части: хранящие данные (M), обрабатывающее данные (C) и визуализирующие это (V)

и теперь внимание, пример реализации:
пользователь тыкает "запустить игру", V получает это событие, определяет какую именно, и пинает C с этим запросом
C проверяет, возможен ли данный запуск (если нет возвращает в V ошибку, не думая о том, как он ее покажет пользователю), подготавливает все необходимое для этого, обращаясь за нужными данными к M, не думая о том, как они там хранятся (локально/генерируются на лету/лежат в каком-то клауд сервисе) и производя собственно сам запуск

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

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

выполняющихся к тому-же и не в главном потоке.

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

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

знаю одного живого человека, пишет на Delphi, код интерфейса отделен от основного кода, код прост и понятен, при отладке матов от него не слышал

Помоему, лучше не накидываться на вес Qt. Это уведёт нас от темы. Идея не в том, что нужно отказаться от VCL в сторону какого-то другого движка.

это было к тому, что HTML+JS, предложенный тобой, не нативный для ОС (ну кроме может быть ChromeOS), и ему нужно где-то запускаться
т.е. либо зависеть от системного браузера (не забудь, что есть индивиды на XP с 6-м IE), либо писать свою прослойку с тем же WebKit, и тащить его за собой

независимости ядра от крашей GUI;

гуи так часто падает, да

о возможности достаточно ненапряжно написать другой GUI;

зачем? вместо распыления сил над работай над разными гуи лучше объединится и сделать один, но хороший

о возможности управлять приложением по сети

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

о возможности поделить работу над проектом на 2 команды

это можно сделать и так