Mod SupportSo, you know what mod security level you're going to use. So, how do you implement it? The popular - and to my mind, most logical - approach, is to make your game itself a mod. Sort of a 'default' mod - if no mod has been loaded by the player, load the 'yourgame' mod, and play it. In that way, almost all problems are solved. You simply make your pseudo-mod responsible for all the things you want to be modifiable, and make your game engine take care of the rest. If you wanted to customize only the levels and artwork, then make your pseudo-mod responsible for loading them, and make the game responsible for everything else, the AI, the UI, and so on. This doesn't necessarily have to be done using code. Half-Life uses a file in the mod's directory called 'liblist.gam' which lists important things like the first map to be loaded, or the name of the mod. There's no code to be seen; the file is simply loaded by the game, put into the appropriate place, and the mod runs seamlessly. However, if you wanted to support code, that gets a little harder Mod-CodeFirstly, you need a safe place to store your code. It can't be a standalone app - because the mod needs the game to run. So, the popular approach is to use a DLL (Note that the approach is often the same when the file extension on the code files is something random - they just change it to confuse everyone =] ). And voila! A single file that the game can load, and get pointers to the code within. This works especially well coupled with a C++ - style vtable - you have some pointers to functions, which can be assigned to point to the DLL, or to point to the game's default functions. The engine can just use the pointers, and not worry about where the code is that it's calling. ConclusionIt's been a little slapdash, but I think I've covered everything. And if I haven't - well, we're game programmers, the geniuses of the planet - we can find our own solutions! =] Questions, comments, hate mail, nudie pics (heh heh) - send 'em to superpig@gamedev.net |