[.net] Seperation Of Game Elements
Author
Not sure if this post should be in here or the Architecture forum, but as the code is C# this seems like a good place.
I have been thinking about code seperation, having an engine, a game dll and a exe file which can load those game dlls. Much like the way Quake and other games seperate their elements.
Anyhow I roughed together some code which does just that, get it here, and wanted to get some thoughts on the way i'd approached the problem.
FYI Visual Studio 2003, DirectX 9c
Probably best to keep the same directory structure as I have some post build steps which copy files around ...
So the loader is currently a DOS app which gets a list of directories under it's current location and then scans those directories for a file called novusgame.dll. When it finds the dll it uses reflection to load the assembly and then checks for the existence of the INovusGame interface (which is defined in NovusCore). If the interface exists then it casts the loaded object to the interface and gets the name of the game dll from a property and then runs the games SetupGame method ...
This method creates the Windows form and the NovusCore GfxEngine class, it passes the form to a method in the GfxEngine class where the DirectX initialisation is done (very simply) ...
A GameLoop is then started and rendering is carried out ...
Thats all it does at the moment, this was just an exercise in logistics of seperating the elements thereby allowing the sourcecode distribution of a game library without having to give away the complete engine.
Your thoughts would be appreciated.
Cheers
MC
"When it finds the dll it uses reflection to load the assembly and then checks for the existence of the INovusGame interface (which is defined in NovusCore)."
Careful with this bit - you'll inevitably have a scenario of someone implementing the interface, and then inheriting the class that implemented the interface to keep their code abstract and clean; or the worse scenario of someone making a "base" implementation of your interface for other people to consume and extend.
You should probably supply the interface, but only load classes marked with a special attribute that you provide to ensure you *only* load the classes the developer wanted.
Careful with this bit - you'll inevitably have a scenario of someone implementing the interface, and then inheriting the class that implemented the interface to keep their code abstract and clean; or the worse scenario of someone making a "base" implementation of your interface for other people to consume and extend.
You should probably supply the interface, but only load classes marked with a special attribute that you provide to ensure you *only* load the classes the developer wanted.
I agree with Anonymous here... custom attributes rock the cazbah when it comes to this type of plugin architecture and dynamic discovery of features.
And just to add a little more, although probing sub-directories is nice, it may be nicer to allow a manifest/config to specify directories to probe (in case they are not below the directory of the laucher app) as well as allowing for a specific assembly to be nominated (to save probing and loading a crapload of assemblies that you may not even need for the current game).
[edit] - seems the grammar fairy went on holidays
And just to add a little more, although probing sub-directories is nice, it may be nicer to allow a manifest/config to specify directories to probe (in case they are not below the directory of the laucher app) as well as allowing for a specific assembly to be nominated (to save probing and loading a crapload of assemblies that you may not even need for the current game).
[edit] - seems the grammar fairy went on holidays
Author
Custom attributes, I haven't looked into those much, but I did this morning and have implemented a simple attribute class which the game libraries must attach.
I like it, allows you to query for the attributes before you actually have to instantiate a class with reflection. Very cool, thanks for pointing me in that direction.
I also agree with Bad Monkey regarding the flexibility of the directory locations, I was just reading the sub-directories for a speedy test implementation.
I have uploaded the modified code for anyone who is keen to look at using custom attributes, get it here.
I like it, allows you to query for the attributes before you actually have to instantiate a class with reflection. Very cool, thanks for pointing me in that direction.
I also agree with Bad Monkey regarding the flexibility of the directory locations, I was just reading the sub-directories for a speedy test implementation.
I have uploaded the modified code for anyone who is keen to look at using custom attributes, get it here.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
