Programming a Game Engine
Author
Hey there, I've decided to program a game engine. I'd like to know what API would be best suited for the job, to make it somewhat "future-proof".
My original choices were:
- Direct3D for Graphics
- DirectSound/DirectMusic or DirectShow for Sound
- DirectInput for Input
- DirectPlay for Networking
However, from what it looks like, Microsoft have been making several very large changes, for example, DirectPlay is now deprecated, and with the introduction of Windows Vista, I'm expecting there to be major shifts in how they expect games to be coded. I'm not sure exactly, but XNA? DirectX 10? I'm not quite sure on this myself.
I've also decided that I'm not going to use any external libraries, such as SDL or OpenAL, RakNet or otherwise, since this is primarily for my benefit, and using external libraries is somewhat cheating, at least, to me anyway. My engine, my code, more or less. Even if it goes against common sense.
Would anybody be able to tell me which API would be best suited for each component, in order to be future-proof, preferably something readily avaliable from Microsoft, like DirectX?
Thanks,
Steven
any game engine worth it's weight should be completely independent of APIs like DirectX.
There's no way to really futureproof by tying yourself to a single API, because even APIs evolve and change. DirectX 3.0 is not DirectX 5.0, let alone DirectXNA.
The best way to get an upgradable engine would be to create a facade. Hide all your direct API within their own classes. That way, when the next best API comes out, you can simply rewrite the class that is affected without rewritting the actual engine.
The best way to get an upgradable engine would be to create a facade. Hide all your direct API within their own classes. That way, when the next best API comes out, you can simply rewrite the class that is affected without rewritting the actual engine.
Quote:Original post by Morpheus011
any game engine worth it's weight should be completely independent of APIs like DirectX.
Couldnt have said it better.
Author
I see. I've already started on this, and I've set it up to use DLLs and an abstract class as an interface for each component, i.e. sound, networking, etc, in order to let me switch APIs as needed, I just needed to know which API would be best for each section, if not the ones I mentioned above.
Nah, I won't post what I initially wrote. I'm not that drunk. Yet.
In a nutshell, don't write an engine. Engines are massive, generic pieces of software written by teams of experts with years of experience. They're damn-near impossible for a single amateur coder to finish. Even a simple one. Program a game instead. Or a bunch of games. They're fun to code, they're great for portfolios, and they'll give you a taste of all areas of game programming. Here speaks the voice of (a fair bit of) experience (having gone from raw green noob to final-year CompSci degree student).
Also, it's only cheating if you use someone else's code without understanding what it does and/or without acknowledging them. If it saves you time, use it, and give a shout-out in the credits!
</drunk_post>
In a nutshell, don't write an engine. Engines are massive, generic pieces of software written by teams of experts with years of experience. They're damn-near impossible for a single amateur coder to finish. Even a simple one. Program a game instead. Or a bunch of games. They're fun to code, they're great for portfolios, and they'll give you a taste of all areas of game programming. Here speaks the voice of (a fair bit of) experience (having gone from raw green noob to final-year CompSci degree student).
Also, it's only cheating if you use someone else's code without understanding what it does and/or without acknowledging them. If it saves you time, use it, and give a shout-out in the credits!
</drunk_post>
If you're looking to program games, don't reinvent the wheel. If someone provides a library that would be suitable for your purposes, by all means, make use of it. It's not cheating. But just as an act of courtesy, credit the library developers someplace.
If, however, you really want to develop a game engine from the ground up, writing each subsystem on your own, then like others have said, use a facade and/or bridge pattern to hide the implementation details of the underlying API. Realize you'll be in for a good amount of work going this route, and you'll redesign/rewrite your engine many times over as you learn. It could be a good way of getting experience architecting a piece of software, but if you're primary interest is in making games, there are much less painful routes to go about. If you haven't checked it out already, the Alternative Game Libraries forum has a post with a large list of a variety of libraries you can use for game development, broken down into categories like graphics, sound, networking, GUI, etc.
If, however, you really want to develop a game engine from the ground up, writing each subsystem on your own, then like others have said, use a facade and/or bridge pattern to hide the implementation details of the underlying API. Realize you'll be in for a good amount of work going this route, and you'll redesign/rewrite your engine many times over as you learn. It could be a good way of getting experience architecting a piece of software, but if you're primary interest is in making games, there are much less painful routes to go about. If you haven't checked it out already, the Alternative Game Libraries forum has a post with a large list of a variety of libraries you can use for game development, broken down into categories like graphics, sound, networking, GUI, etc.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement