# XNA Moddable Game - Architecture Design and Reflection

I've decided to embark on an XNA moddable game project of a simple rogue style. For all purposes of this question, I'm going to not be using a scripting engine, but rather allow modders to directly compile assemblies that are loaded by the game at run time. I know about the security problems this may raise.

So in order to expose the moddable content, I have gone about creating a generic project in XNA called MyModel. This contains a number of interfaces that all inherit from IPlugin, such as IGameSystem, IRenderingSystem, IHud, IInputSystem etc.

Then I've created another project called MyRogueModel. This references MyModel project, and holds interfaces such as IMonster, IPlayer, IDungeonGenerator, IInventorySystem. More rogue specific interfaces, but again, all interfaces in this project inherit from IPlugin.

Then finally, I've created another project called MyRogueGame, that references both MyModel and MyRogueModel projects. This project will be the game that you run and play. Here I have put the actual implementation of the Monster, DungeonGenerator, InputSystem and RenderingSystem classes. This project will also scan the mods directory during run time and load any IPlugins it finds using reflection and override anything it finds from the default. For example if it finds a new implementation of the DungeonGenerator it will use that one instead.

Now my question is, in order to get this far, I have effectively 2 projects that contain nothing but interfaces... which seems a little... strange ? For people to create mods for the game, I would give them both the MyModel and MyRogueModel assemblies in which they would reference. I'm not sure whether this is the right way to do it, but my reasoning goes as follows :

If I write 1 input system, I can use it in any game I write.

If I create 3 rogue like games, and a modder writes 1 rendering system, that modder could use the rendering system for all 3 games, because it all comes from the MyModel project.

I come from a more web based C# role, so having empty interface projects doesn't seem wrong, its just something I haven't done before. Before I embark on something that might be crazy, I'd just like to know whether this is a foolish idea and whether there's a better (or established) design principle I should be following ?

• Seems good. In my experience, if you have a ton of Interfaces and you're doing C# or Java, then you're Doing It Right.
– Anko
Dec 13 '12 at 10:17
• Cool, would it be seen as ok that abstract classes can make up part of these base projects too (MyModel), rather than just having them consist of interfaces ? Dec 14 '12 at 10:24
• The difference between abstract classes and interfaces is that abstract classes define some behaviour. Interfaces define, well, interfaces. If MyModel defines some sort of behaviour expected of all subclasses by default, it ought to be an abstract class. This article might help you decide what's right.
– Anko
Dec 14 '12 at 16:25
• Yes, I'm using abstract classes to have some very basic implementation of, say, the IInputSystem. I was just wondering whether mixing interfaces together with abstract classes was the done thing. I don't want to have to get all the modders of certain systems to have to write the same basic code. I can't mark a comment as an answer, but if you'll like to put one in, I'll mark it. Dec 14 '12 at 17:27
• You're likely doing everything right then! By the way, the Code Review Beta site might be a better place for getting feedback on code structure.
– Anko
Dec 14 '12 at 17:33