This is one case where I also advocate adding a wrapper for abstraction. What you're aiming for may be less of having it work on multiple platforms, but instead actually avoiding the dreaded vendor lock-in. The problem is that in today's requirements, DirectX may be the way you're going, but you simply can't visualize three years ahead with certainty and know that that will always be the plan. The moment the plan changes, management will on you assuming it's an easy task to switch and wondering why you coded things so poorly that transitioning to a different system can't be done. On some teams, management will begrudgingly accept the difficulty of the task and on some they will start looking for a new team.
In the case of DirectX or OpenGL as a whole, anyway, I find the APIs are written too low level to be used directly and so naturally I am writing higher level classes around them as I'm working through, so the overhead of making these classes API-independent becomes further reduced.
Of course you have to weigh the trade-offs, and sometimes getting it done now 10% more quickly is more valuable than having to spend 50-100% effort to refactor/rewrite later (Caveat: I find that this is less often the case than most people perceive, however).
Abstraction in game engines
Quote:Original post by SneftelBy changing your code. Writing an abstraction layer that abstracts out everything you think could possibly change between graphics systems will be both overkill and futile.
So basically you're calling the work on Unreal Engine 3, Ogre, and Irrlicht both overkill and futile? That's simply rediculous.
Quote:Original post by Halifax2Quote:Original post by SneftelBy changing your code. Writing an abstraction layer that abstracts out everything you think could possibly change between graphics systems will be both overkill and futile.
So basically you're calling the work on Unreal Engine 3, Ogre, and Irrlicht both overkill and futile? That's simply rediculous.
just because they do, doesn't mean you should.
after all, they have development teams .
Quote:Original post by Matt_D
just because they do, doesn't mean you should.
after all, they have development teams .
Exactly my point. You shouldn't even be making a game engine in the first place, but rather picking up an existing one that has been made by a development team already and helping to improve it. Thus gaining your desired experience.
At any rate, I find that just "changing your code" is highly inefficient. By abstracting away to a higher level you have the advantage of possibly enlisting future developers to work in tandem with another API.
Quote:Original post by Halifax2
Exactly my point. You shouldn't even be making a game engine in the first place, but rather picking up an existing one that has been made by a development team already and helping to improve it. Thus gaining your desired experience.
well, in some cases, there isnt an engine out there which fits your purpose, or perhaps you want to write an engine. An off the shelf option isnt always viable in all cases.
Quote:
At any rate, I find that just "changing your code" is highly inefficient. By abstracting away to a higher level you have the advantage of possibly enlisting future developers to work in tandem with another API.
in realistic terms, its more about the frequency of change. Graphics API's tend to change rather infrequently, and unless your really trying to target disparate platforms or your intending on bolting your engine on top of someone elses (to use as a UI engine for example, and thus will need to use someone else's renderer) its really not worth wrapping the entire lot.
there are advantages, but there is also cost, weigh the two up, do the one that has the most beneficial outcome.
Author
Thank you all for your piece of advice. I've been reading a little and skimming through some open-source game engines like WildMagic and Ogre. Most of them create wrapper classes and their own math system. I think the wisest option is to stick with DirectX at all. So much abstraction is useful if are in a professional team that plan to port its engine to other platforms. For a programmer like me, it makes no sense. I am very comfortable working with DirectX and Windows is the standard platform for gaming. It's always tempting to build your own game engine, but sometimes it might be more beneficial to put your efforts on improving your skills in graphics, AI, maths, physics, etc. rather than reinventing the wheel just for fun.
Quote:Original post by NeneThey don't have to. A game written for DX9 will work fine on DX11 or DX12 or any other version for the forseeable future.
But commercial games cannot allow being re-written for D3D9, D3D10, etc.
Quote:Original post by Halifax2No, you misread.
So basically you're calling the work on Unreal Engine 3, Ogre, and Irrlicht both overkill and futile?
Quote:Original post by SneftelQuote:Original post by Halifax2No, you misread.
So basically you're calling the work on Unreal Engine 3, Ogre, and Irrlicht both overkill and futile?
Yes, it does appear as though I misread. Sorry Sneftel.
Quote:Original post by Nene
Thank you all for your piece of advice. I've been reading a little and skimming through some open-source game engines like WildMagic and Ogre. Most of them create wrapper classes and their own math system. I think the wisest option is to stick with DirectX at all. So much abstraction is useful if are in a professional team that plan to port its engine to other platforms. For a programmer like me, it makes no sense. I am very comfortable working with DirectX and Windows is the standard platform for gaming. It's always tempting to build your own game engine, but sometimes it might be more beneficial to put your efforts on improving your skills in graphics, AI, maths, physics, etc. rather than reinventing the wheel just for fun.
What better way to learn those things then writing your own engine. Just because you are reinventing the wheel doesnt mean it will take all your time... a very simple forward renderer using DX is not that big of a deal to write with all the samples out there, and then you can work on other subsystems with it. I think there is a lot of value in writing your own engine, and an importance in understanding just what the heck a renderer is doing with your model or game object. Then again, what is your purpose? if your purpose is to write a 3d fps game in 2 months, then yeah, you might want to grab an engine. however if you are trying to expand your skills, then writing a simple renderer and implementing subsystems would work. Personally, i think expanding on an existing engine is cool and all, but can be frustrating and time consuming learning the code base. DX9/10, OpenGL, whatever. Those are APIs, in the end they should be somewhat invisible to the user and the experience (unfortunately isnt always the case, save for some/all? blizzard games)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
