Это зависит от того, как вы хотите создать свою мод-систему. Я исследую два из них.
SDK
Скорее всего, вам потребуется, чтобы ваши моддеры использовали тот же язык, что и вы, и загружали моды через отражение (или подобное, в зависимости от того, какой язык вы выбрали). Это, очевидно, ограничит вас языками, которые могут выполнять позднюю привязку - и многие могут это сделать (даже C может выполнить позднюю привязку с некоторыми хитрыми LoadLibraryхитростями). Вы можете даже сделать мета-моддинг, где мод может содержать другие моды (например, скриптовые моды).
Первая проблема с этим подходом - скрытие внутреннего состояния. Взяв, например, C #, моддер может просто использовать отражение для доступа к закрытым членам, C также может это сделать (хотя требуется больше усилий).
Вторая проблема - хостинг. Людям не очень нравится чужой код, работающий в их системе без песочницы. В худшем случае вы могли бы написать мод, который настраивал бы «семенную коробку»; если он был установлен у интернет-провайдера, это может нанести серьезный вред их репутации.
Scripting
Моддеры будут использовать язык, такой как Lua, для создания модов. Вам потребуется либо язык, который может вызывать нативный код (для взаимодействия с Lua); или вам придется написать свой собственный язык сценариев на выбранном вами языке.
Первая проблема заключается в том, что интерпретируется большинство языков сценариев, что может быть неприемлемо для систем реального времени (хотя, см. LuaJIT); такие как игры.
По иронии судьбы вторая проблема все еще существует здесь; Взяв Lua в качестве примера, я был крайне разочарован тем, что в библиотеку core / default включены функции «обнуления», что делает его совершенно бесполезным в качестве изолированной среды (без больших усилий, удачи и обслуживания), трудно изобразить , как я зол об этом, но я действительно надеюсь , что они пили некоторые сильные коктейли , когда они включали в себя эти анти-функцию . Очевидно, вы могли бы легко избежать этого, если бы вы катались на своем собственном языке (см .: UnrealScript).
Наконец, стоимость взаимодействия со скриптовым движком может быть чрезмерной - опять-таки, взяв Lua в качестве примера, в сочетании с C #: C # имеет значительные накладные расходы при вызове нативных функций (через P / Invoke), а Lua - довольно «болтливый» API. Это может привести к проблемам, если при разработке «SDK-скрипта» требуется много разговоров между вашим основным языком и языком сценариев (обратите внимание, что в C на самом деле такой проблемы нет). Опять же, вы можете избежать этого, написав свой собственный язык сценариев (и в случае C # компилируя его в MSIL) и выполнив его самым быстрым способом в вашей [виртуальной] среде.
Поскольку скрипт в сущности работает в совершенно другой системе, чем ваш основной код, вы можете полностью контролировать доступ к внутреннему состоянию (если только они не делают какие-то причудливые вещи с ранее упомянутыми функциями оболочки).
Вывод
Я немного отклонился от темы, однако, что вы можете получить из этой стены текста, так это то, что вы должны иметь возможность создавать изменяемую игру на любом языке (я бы рискнул сказать, что вы можете ) - но на некоторых языках. может привести к большей работе. Я немного анальный о безопасности? Да, вы должны быть тоже, когда дело доходит до кода пользователя.