This will probably be a very simple question to many but anyway, how do you create a API for a game to allow modding, etc...?

Does it have something to do with loading libraries at run-time using dynamics? (C#). I haven't reached that topic in my book or on plural-sight yet but I know it allows you to plug in assemblies during run-time, yes?

Anyway all replies are appreciated.

Thanks,
Xanather.

One way you could do it is link your game against an empty dynamic library and run a various empty functions from that library at certain points of your code passing game data to those functions, that way a modder could create there own version of your empty library and essentially be able to run their code at different points in your code like a plugin.

This is one way of course and I'm not sure its the best way and I don't know how c# would differ from the languages I'm used to in that respect.

Ok i will look into that thanks.

I strongly suggest against linking to libraries.
Historically, library linking has been a pain to work with and albeit it's got somewhat safer now, better methods are now available.
In particular, look at integrating a scripting language. Suddenly, your code becomes an asset, just like a texture. This does not magically imply your program can now "do everything".

FYI:
Id software only allowed library linking as primary modding technique in Quake 2. All other products were script-driven.
Unreal Engine became king of the hill by providing a powerful scripting language (UnrealScript, in case you have not heard).

This is not to say the days of library linking are gone, but I'd consider them a last resource.

I see, how do one go about integrating a scripting language? Im using C#, possible?

Thanks,
Xanather.

This is fairly old now (circa VC2005), but it might give you a few clues.....

http://nccastaff.bou...ginExample2.zip

Also worth paying attention to the App/bin/scripts folder. You may find that some of the .NET classes used have been deprecated in favour of newer ones (I've not used .NET for a few years)

This example simply provides a core API dll (used by the App). The DLL's and scripts link against the API dll, and all communication goes via that lib. Technically speaking it doesn't really provide scripting support as such. It actually just compiles and links the source files into a DLL in memory. In effect, the scripts are identical to the plugin source. It may be ok for some people, although I guess a lot of people would prefer to have a much more immediate interpretted language. Depends on your needs I guess, but it's one relatively simple solution.

\edit

Just tried compiling it under VC2012. The CppPlugin doesn't work off the bat, because it gets built with a newer version of .NET. If you change the .NET framework used for the other plugins and the app, to the latest .Net framework (4.5 under VC2012), it works fine (albeit with deprecation warnings in the build). If you don't have VB or C++ installed, just nuke the other DLL's and scripts.

I strongly suggest against linking to libraries.
Historically, library linking has been a pain to work with and albeit it's got somewhat safer now, better methods are now available.
This is not to say the days of library linking are gone, but I'd consider them a last resource.

I'm struggling to see why this is difficult in a language like C# that has reflection built into it? It's significantly less error prone that writing a tonne of script bindings imho...

I'm not well aware of how C# linking works, but I'd be extremely careful about allowing complete control of the base system.
But your point is taken, perhaps working with package/private access could be enough.

Personally, given the increasing popularity of portables and stuff not natively running C#, I still think scripting is the way to go.
BTW, I'm struggling to see why one should need to write "a tonne of script bindings".

I've found LuaPlus http://luaplus.org/ to be pretty easy to work with for integrating scripting languages.

Ok, thanks, I think assembly linking is the way to go. I will look into script bindings though.