Jump to content
  • Advertisement
Sign in to follow this  
EmptyVoid

Infinitely Expandable Game Engine.

This topic is 3713 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

Well I'm getting tired of rebuilding my game engine. I've been working on it for 12 years and I've had to rebuild it countless times and I'm about to do it again so I can use DirectX10. I had a idea so I'll never have to wast time rebuilding it again. It's a plug-in based engine that works kinda like 3DS Max. Your able to compile a plug-in under C++ with a SDK and simply place the plug-in in to a folder. The plug-in will act as a separate program in that it will use headers like d3d10.h which will only be compiled in to the plug-in and not the engine. The engine should be able to send and receive data to and from the plug-in. What would be so great about this is once I compile a plug-in like a graphics plug-in that uses DirectX9 then I find that I need to upgrade, I can then create one for Directx10 and still have the other one as a fall back. If the machine which my engine is running on does not support DirectX10 then it can use the DirectX9 plug-in or even a OpenGL plug-in. Does anyone know how I would be able to do this?

Share this post


Link to post
Share on other sites
Advertisement
It's certainly doable, and many cross platform engines uses plugins to abstract away the platform dependent code. If you want a concrete example, I believe Ogre uses plugins for the render kernel.

The way to do it is to make a higher level interface (abstract class) and the create a dynamic link library (.dll on windows, .so on linux) and load it at runtime. Have the plugin create an instance of it's internal implementation of the interface and return it to you. In the rest of you code you access the instance through the interface. In this way you don't have to know anything about what goes on in the plugin.

The downside is that you have to make your own interface that supports everything you need. You quickly end up basically making a complete copy of Direct3D or OpenGL. So you might want to take a step back, and implement some higher level logic in your interface. Think What Do I Need To Do, instead of What Steps Do I Need To Make It Work.

Anyway, good luck.

Share this post


Link to post
Share on other sites
Your can never ever make a software future-proof nor can you ever make it infinitely expandable in terms of flexibility and feature-set. There are well-researched and proven methodologies to adhere to in order to prolong a software's lifetime but you'll never get to a point when you can sit back and say "Well, that was about it". The world of computer programming as we've come to know is in constant motion. A software is a living and breathing being so you have to cope with changes. As a result, it's pretty common for individuals to work on softwares during their entire adulthood, let alone a decade or so. [smile]

Having said that, there are accepted guidelines to follow. As you've come to realize, you generally have to introduce some degree of abstraction in your system to loosen the coupling between subsystems and minimize the negative side effects that propagate whenever a change is made. The higher the abstraction, the greater the flexibility, the greater the performance hit. As most things in the world of computer science there are trade-offs and tough decisions to be made.

All in all, while you shouldn't expect your new design, or any other design for that matter, to be infinitely expandable, it's a move in the right direction. I'd suggest you find a good resource on software engineering and programming methodologies and start reading. The rabbit hole goes much deeper than choosing the correct rendering API at run-time. You'd encounter a lot of problems and headaches if you're not well equipped for this long journey.

Share this post


Link to post
Share on other sites
I dunno, but hes spent 12 years of his life building it so one would think a moderate understanding of design patterns and modular software architecture would come up.. you know.. at some point? Do you have any particular reason to move up to support DX10 at the present? You do realize thats a vista-only DX version right? (people are downgrading off that OS at an alarming rate). Are you planning on releasing your engine publicly? If not, I wouldent really worry about it, and the market for engines isnt super pretty unless you lowball yourself heavily and it was used to produce a commercial game in the past (no, not independently), and then you still better have an edge against the freebies at least. Is there any reason to move to a modular architecture now? Chances are, your going to have so much in the content pipeline that your 12 year old rendering engine is the least of your worries.

Share this post


Link to post
Share on other sites
Quote:
Original post by PaulCesar
I dunno, but hes spent 12 years of his life building it so one would think a moderate understanding of design patterns and modular software architecture would come up.. you know.. at some point? Do you have any particular reason to move up to support DX10 at the present? You do realize thats a vista-only DX version right? (people are downgrading off that OS at an alarming rate). Are you planning on releasing your engine publicly? If not, I wouldent really worry about it, and the market for engines isnt super pretty unless you lowball yourself heavily and it was used to produce a commercial game in the past (no, not independently), and then you still better have an edge against the freebies at least. Is there any reason to move to a modular architecture now? Chances are, your going to have so much in the content pipeline that your 12 year old rendering engine is the least of your worries.


The reasons I want to use DirectX10 is I have been working on rendering procedural planets because it would allow much more creative freedom for a idea I had for a game but DirectX9 does not have a unified shader which is forcing me to use a much slower method for generating noise. It just makes since to use DirectX10 but I would still like the work that I have done so far to be used for compatibility without writing 2 copies of the engine.

I'm starting to think it's a bit more then I can handle at the moment. I'd like to work on another project so I can build my collection of models, shaders and at least have a complete demo of some of my work. But I'd like the work that I do on that project to be transferable so I can expand on it. Such as making a plug-in for procedural planets after I have the basic things needed for a game.

I also am having problems deciding on which physics engine to use so the plug-in idea would fix allot of things. Plus it would make a very expandable engine which I will be able to use for many years to come on later projects.

Share this post


Link to post
Share on other sites
If DX10 will let you do what you want, just upgrade it for DX10 and actually USE your engine. It will be quite usable for up to 5 years without a total re-write for DX11.

Share this post


Link to post
Share on other sites
Can someone link a paper about modular programming with C++?

Edit: Found something pretty useful.

[Edited by - EmptyVoid on June 16, 2008 8:06:41 AM]

Share this post


Link to post
Share on other sites
It is less an issue of C++ itself but of the dynamic library architecture enforced by the running OS. In C++, you'll simply have to define an interface class (usually at least virtual, but also often pure virtual) for each kind of extension you'll have in the engine. Implementations then have to make the class concrete. Not _that_ simple, but useful and workable, is my approach as described in the following:

At the lowest level there is the Extension class; it is pure virtual, non-copyable, and provides the administrative interface common to all extensions (kind, name, revision, various textual information for humans to look for). It embeds a template class for a registry as well.

IOFormat : public Extension is an example for the next level of Extension; here a specific semantic is added, in this case it means "a class that describes a file format" and may provide factories for importers and exporters). Obviously, its interface is extended by belonging routines, e.g. IOFomat::newImporter() for the factory of importers. This level of a class also embeds an instance of the aforementioned Extension::Registry class, so that IOFormat::registry is the point where to ask for (in this case) a specific IOFormat by its name, or where to iterate all registered instances. Other kinds of extensions work exactly the same way; each one has a specific base class derived from Extension, and provides a Registry.

The next interesting aspect is the PlugIn class. A plug-in in this sense is a wrapper around one or more belonging specific Extension instances. That means that a PlugIn can provide more than 1 extension. E.g. the SVG::PlugIn provides an SVGIOFormat for the file format as well as SVGraphics as Graphics sub-system (another kind of Extension). Sense of PlugIn is to resolve dependencies. It allows to register an Extension only if e.g. another Extension is already registered. With such a method it is possible to install plug-ins even with mutual dependencies. To make plug-ins also observable by humans, its base class PlugIn is itself derived from Extension.

I don't restrict PlugIn to be loaded by a dynamic library; actually also the main part installs some of its stuff in form of plug-ins. However, Module is the class that deals with dynamic libraries. It provides static routines to load libraries and return an instance of Module (OS dependend) that represents that library. That class also provides routines to dynamically resolve addresses, but that is not needed for plug-ins. Instead, I embed static PlugIn instances into the libraries, using the OS and the class c'tor to automagically register the PlugIn and hence start the installation process. People may notice that one has no control over the order of instantiation, and that is correct, but has never played a role for me so far. One can instead use those both DSO routines that are invoked after the library is loaded.

From the system's point-of-view, whether Modules are loaded can be handled in several ways. Main parts like sub-systems (like the OP's D3D10/D3D11 as Graphics) may be loaded directly or by corresponding entries in the configuration. Other parts may be loaded by user interaction or level file demands.

When it comes to the library itself, the classes may need to be marked exported or not. That stuff is highly OS dependend. The above isn't a detailed description what to do, but hopefully gives a hint how an extension system may be structured.

Share this post


Link to post
Share on other sites
This is kind of off topic, but I had an idea like this for a 'simple' desktop application. I was going to create this Dungeons and Dragons like desktop manager where you would use it as you played to store your stats and such. The key point was that I didn't want to build it around a single ruleset so I wanted 'packages' that you would drop in a folder and when you opened the app would choose which ruleset it would use and it would change to use those rules. The application was pretty simple to code to a specific ruleset but once you think about previous versions and future versions the scope of the project and idea balloons to infinity.

Moreso the problem with this idea is that new versions are typically built to correct things in the old version so in theory, if you are building for older versions you're creating useless code. In the DnD app case it might be useful because people use older rule books a lot but building something for DirectX or some API wouldn't be logical, how many people currently still use DirectX 7 consistantly? But, that really only applies to an app you need to preserve previous versions for.

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!