To zależy od tego, jak chcesz zaprojektować swój system modów. Zbadam dwa z nich.
SDK
Najprawdopodobniej będziesz wymagał od modderów używania tego samego języka co ty i ładowania modów poprzez odbicie (lub podobny, w zależności od wybranego języka). To oczywiście ograniczy cię do języków, które potrafią późno wiązać - i jest wielu, którzy potrafią to zrobić (nawet C może zrobić późne wiązanie za pomocą sprytnych LoadLibrary
sztuczek). Możesz nawet zrobić trochę meta-modowania, gdzie mod może obsługiwać inne mody (np. Mody skryptowe).
Pierwszym problemem związanym z tym podejściem jest ukrywanie stanu wewnętrznego. Biorąc na przykład C #, na przykład modder może po prostu użyć refleksji, aby uzyskać dostęp do prywatnych członków, C może również to zrobić (chociaż wymaga więcej wysiłku).
Drugim problemem jest hosting. Ludzie nie lubią obcego kodu działającego w ich systemie bez piaskownicy. Jako najgorszy scenariusz możesz napisać mod, który konfiguruje seedbox; jeśli zostanie zainstalowany u dostawcy usług internetowych, może poważnie zaszkodzić jego reputacji.
Skrypty
Modders używałby języka takiego jak Lua do tworzenia modów. Będziesz albo potrzebował języka, który mógłby wywoływać kod macierzysty (do interfejsu z Lua); albo będziesz musiał napisać własny język skryptowy w wybranym przez siebie języku.
Pierwszy problem polega na tym, że większość języków skryptowych jest interpretowana, co może być nie do zaakceptowania w systemach czasu rzeczywistego (chociaż patrz LuaJIT); takie jak gry.
Jak na ironię drugi problem wciąż tu istnieje; biorąc za przykład Luę, byłem bardzo rozczarowany, że ma funkcje „wyrzucania” zawarte w bibliotece podstawowej / domyślnej - co czyni ją całkowicie bezużyteczną jako środowisko sandboxowane (bez dużego wysiłku, szczęścia i konserwacji), trudno jest pokaż, jak bardzo jestem na to zły, ale naprawdę mam nadzieję, że pili mocne koktajle, gdy dodali te anty-funkcje . Można oczywiście łatwo tego uniknąć, jeśli stworzysz własny język (patrz: UnrealScript).
Wreszcie, koszt interakcji z silnikiem skryptowym może być wygórowany - ponownie biorąc Lua za przykład w połączeniu z C #: C # ma znaczny narzut podczas wywoływania funkcji natywnych (przez P / Invoke), a Lua jest dość „gadatliwym” API. Może to prowadzić do problemów, jeśli sposób zaprojektowania „zestawu SDK skryptów” wymaga dużej ilości rozmów między językiem podstawowym a językiem skryptowym (zauważ, że C tak naprawdę nie ma tego problemu). Ponownie możesz tego uniknąć, pisząc własny język skryptowy (aw przypadku C # kompilując go do MSIL) i wykonując go w najszybszy sposób w środowisku [wirtualnym].
Ponieważ skrypt działa zasadniczo w systemie zupełnie innym niż kod podstawowy, możesz całkowicie kontrolować dostęp do stanu wewnętrznego (chyba że wykonują jakieś wymyślne czynności z wcześniej wspomnianymi funkcjami powłoki).
Wniosek
Odwróciłem się trochę od tematu, jednak to, co możesz zasadniczo wyciągnąć z tej ściany tekstu, to to, że powinieneś być w stanie stworzyć grę z możliwością modyfikacji w dowolnym języku (zaryzykowałbym stwierdzenie, że możesz ) - ale w niektórych językach może prowadzić do większej pracy. Czy jestem trochę analny w kwestii bezpieczeństwa? Tak, powinieneś być też jeśli chodzi o kod użytkownika.