Internal и External читы: в чем разница и как устроены разные типы игрового софта

В описании игрового софта нередко можно увидеть пометку Internal или External. Иногда производитель вообще не объясняет, что она означает, будто пользователь родился с этим знанием. Между тем речь идет не о наборе функций и не о «крутости» программы. Эти слова описывают то, каким способом софт взаимодействует с игрой.

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

Internal: работа внутри игры

Название Internal в данном случае довольно буквальное. Основная часть программы выполняется внутри процесса игры.

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

Отсюда и репутация Internal как более функционального варианта. Но ставить знак равенства между «Internal» и «больше возможностей» все же не стоит. Многое зависит от конкретной игры и от того, что вообще пытался сделать разработчик.

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

External: отдельная программа рядом с клиентом

External не работает внутри игрового процесса. Обычно пользователь запускает игру и отдельное приложение, которое существует самостоятельно.

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

Это удобно в ситуациях, когда нет необходимости переносить всю логику непосредственно внутрь игры. Отдельное приложение проще изолировать, перезапустить или обновить независимо от самого клиента.

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

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

В чем разница для обычного пользователя

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

• Internal работает внутри игрового процесса, External остается отдельным приложением;
• внутренние решения обычно теснее связаны с клиентом, поэтому сильнее зависят от его изменений;
• External проще отделить от игры, например закрыть или перезапустить независимо;
• набор возможностей нельзя определить только по архитектуре: два продукта одного типа могут отличаться очень сильно;
• производительность тоже зависит от конкретной реализации, а не от слова Internal или External в описании;
• после обновлений игры оба варианта могут потребовать изменений, просто причины и объем этих изменений бывают разными.

Иными словами, сама архитектура дает представление о принципе работы, но ничего не гарантирует.

Почему Overlay – это не отдельный третий тип

Слово Overlay тоже часто встречается рядом с Internal и External, из-за чего все окончательно начинает выглядеть как набор терминов из документации к космическому кораблю.

На практике все проще. Overlay – это способ вывести элементы поверх игрового окна. Например, так может отображаться интерфейс программы или дополнительная информация. При этом оверлей не говорит, где выполняется остальной код. Он может использоваться в программе с разной архитектурой. Поэтому выражение «External с Overlay» вполне нормально. А вот считать любой софт с картинкой поверх игры автоматически внешним уже неправильно.

Бывают ли смешанные варианты

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

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

В таком случае простой ярлык Internal или External уже не рассказывает всей истории. По этой причине иногда можно встретить продукты, которые разные пользователи относят к разным категориям. Один смотрит на интерфейс и называет программу External. Другой знает, что внутри используется дополнительный компонент, и считает ее Internal. Формально оба могут описывать разные части одного решения.

Что означает работа через драйвер

Еще один термин, с которым рано или поздно сталкивается человек, читающий описание игрового софта, – driver. Драйвер работает на более низком уровне Windows, чем обычное пользовательское приложение. Это уже не просто программа с кнопкой «Запустить».

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

Поэтому громкая надпись «driver-based» в описании – это характеристика архитектуры, а не автоматический знак качества.

Есть ли софт, который не подходит ни под один вариант

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

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

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

Что в итоге лучше: Internal или External

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

Для пользователя название архитектуры вообще не должно становиться главным критерием выбора. Важнее, как ведет себя конкретная версия программы: работает ли она с текущей версией игры, насколько стабильно запускается, понятен ли интерфейс и соответствует ли набор функций тому, что заявлено в описании.

Если свести всю тему к одной фразе, получится так: Internal работает изнутри игрового процесса, External – за его пределами. Но реальный игровой софт давно стал сложнее этой простой схемы, и сегодня в одном продукте вполне могут соседствовать сразу несколько подходов.