Jump to content
  • Advertisement
Sign in to follow this  
MonkeyChuff

[.net] Seperation Of Game Elements

This topic is 4808 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
"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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!