How does your gaming engine and your api (opengl or directx for example) interact with each other? do you have to have a gaming engine to make a game?
Printable View
How does your gaming engine and your api (opengl or directx for example) interact with each other? do you have to have a gaming engine to make a game?
I don't understand what you mean. You create a gaming engine with DirectX or OpenGL. You don't even need them. You can create a gaming engine in a text mode too if you want to.
The engine encapsulates the calls to whatever API you use. But as GaPe said you don't even need to use one of those APIs to make a game engine. Your game engine is basically a modular set of wrappers for the major areas of your game (input, drawing, sound, combat system, etc - whatever your particular game requires).Quote:
Originally posted by Shadow12345
How does your gaming engine and your api (opengl or directx for example) interact with each other?
No, but it will make your life a WHOLE lot easier if you make an engine. It will make finding bugs easier, since everything will be set in it's own section and can be debugged in smaller chunks. It will make it possible to reuse large parts of your code base for future games you make. It will make it easier to modify/maintain. The list goes on.Quote:
do you have to have a gaming engine to make a game?
Basically, when it comes to games:
HaveEngine==Good.
:)
The views that are expressed in this reply are those of the author, and are not necessarily correct. Use your mind to judge what's right and what's wrong, and when you find something wrong, notify me :)
Actually, you have to have a game engine to make a game. A game engine is the code that's compiled and linked to create your game. Whether this code is modular or not, it's the engine.Quote:
do you have to have a gaming engine to make a game?
--------------------------------------------------------------------------------
No, but it will make your life a WHOLE lot easier if you make an engine. It will make finding bugs easier, since everything will be set in it's own section and can be debugged in smaller chunks. It will make it possible to reuse large parts of your code base for future games you make. It will make it easier to modify/maintain. The list goes on.
The GDNet dictionary defines the game engine as "A program code that runs all aspects of the game."
Theoretically, you can write a 3D game in a single function - in your main() function. Practically however, this is somewhat impossible ( It's not actually impossible, it's just so hard that it's nearly impossible )
Modularity, however, is what offers you the abilitiy to extend and upate your engine, keep track of bugs & fix them, ...etc
* The relation between the engine and the API
The engine, is the code that handles all the aspects of the game. It defines the behavior of the game.
This engine has what can be called sub-engines, like a 3D graphics engine, a 3D sound engine, an AI engine, ....etc
Each sub-engine is actually a module that's designed to handle something :
The graphics engine - Handles the visual part of the game. How the game world is displayed
The sound engine - Handles how the game sounds
.
.
.
You essentially define how your game should work, and design the modules accordingly. Some modules are not limited by APIs, the AI module for example - if being written from scracth, without building on 3rd party libraries - doesn't restrict you with anything more than the language & hardware limitations. Thus to design an AI engine, you can just use any design that works on modern computers.
When designing a graphics engine, on the other hand, you have to keep an eye on the limitations and restrictions caused by the graphics API - whether GL or D3D.
In 3D graphics engine, it's often needed that you follow a set of rules or API standards to achieve optimal performance. If you don't, your game would simply suffer from slowness and may not be playable.
In Direct3D for example :
Worlds are always represented by vertices ( You can think of it as a point in space, in case you don't know 3D graphics ). Vertices define your polygons, polygons define your walls, your characters, ... your game world.
When designing a graphics engine that uses Direct3D, you have to design so that you store your vertices in a special Direct3D object called a "Vertex Buffer". If you don't do so, you'll pay a performance penalty.
Also, when rendering your polygons ( drawing things like walls and models on the screen ), there's an optimal number of triangles to be rendered in a single call. Render more triangles than that, and you're not running optimally. Render less, and you're still not running optimally.
These restrictions don't exist - as far as I know - when using GL. Thus when you're using an API, you have to :
1 - Define what your game needs from the API
2 - Check the limitations presented by the API, on the things you decided would be useful to your game
3 - Design your sub-engine ( the one that uses this API ) around the limitations presented, so that you get optimal performance.
* Writing games & game engines
As far as I've seen, it's better to split your game engine into separate modules, and even separate these modules into sub-models.
For example, for a strategy game you need AI. So there's an AI module, this AI module is expected to do a lot of things :
1 - Resource management
2 - Pathfinding
3 - Battle tactics
.
.
.
Each of these points can be a sub-module. Each sub-module should be implemented alone in its own project, and tested thouroughly to make sure it works as expected. Sub-modules can even be divided into smaller sub-modules - that are tested individually - if needed.
That way, you end up by a number of working modules. Then you start joining them with each other to produce a fully working game. Be careful, though, joining modules together isn't that easy. And if you join too many modules together in one time, you might get a load of bugs, bugs that you don't know where they exactly come from ( Virtually, any 2 modules can be conflicting or not working well with each other )
So, it seems to me that the following is the best solution :
When dividing modules, they somewhat form a tree of parent modules and child modules
For example : The AI module is a parent, the pathfinding is a child of the AI module, the terrain recognition is a child of the pathfinding, ...etc
Join the childs modules together to form the parent, and so on.
Basically, you keep joining the modules that are on the same level to create a higher level module, until you get your final modules.
One final note about joining the modules, make sure you design them in a way so that you can expect how the parent module is going to look like.
I use top-down design, where I :
1- Imagine how I want the AI module to work, and then how I'd like the Resource management to work,...etc
2 - Design all the modules from top to bottom ( starting with the high level AI module )
3 - Implement the modules in top-down direction, using empty functions & classes to reflect unfinished things. ( Sometimes I do use bottom-up implementation, when it seems to be better )
I guess it boils down to how you define "game engine".
The GDNet definition is pretty general/generic.
Consider where the term originated from. Physical engines are made of up several components (modularity), just as a game engine is.
Flipcode's definition..
The code that makes up your game is just that: your game code. The sum of the modular pieces is your engine.
Wow you guys are awesome, I'm copying everything that has been written thusfar. Both of your posts have been extremely helpful (and yes Coder I did read your entire post!) Now I just need to learn how to use OpenGL (API of choice for now unless someone wants to convince me otherwise).
I think both of you ended up saying the same thing about the game engine being a 'wrapper' written in a modular fashion. That way makes sense.
Does anyone ever make modifications to OpenGL or DirectX in order for their games to look even nicer. For example they may want the lighting to look particularly special or something.
One last thing, are there any other APIs other than DirectX or OpenGL. Those are the only two I have heard of because they are the most used in games.
You can't modify any API cause you don't have the source for it. And even if you get the source and modify it, you'd have to distribute the new API binaries ( Direct3D/GL dlls ) to the people that play your games. Additionally, that won't be of use because you're limited by the hardware ( and thus you won't be doing anything other than optimizations, and I believe the huge army of professional programmers at microsoft can get this done better than us :) )Quote:
Does anyone ever make modifications to OpenGL or DirectX in order for their games to look even nicer.
Beware of what follows, for I don't use GL so it might not be correct.
In GL, there's something called "GL Extensions". I read somewhere that these extensions enable the programmer to directly access hidden video card capabilities ( caps not supported by Direct3D yet )
Direct3D, on the other hand, is updated every year or so. So you can't do anything but wait for the new version.
When you get to code 3D graphics, you'll realize that the ordinary type of lighting supported by D3D/GL is called vertex lighting which really looks similar on any card/API.Quote:
For example they may want the lighting to look particularly special or something.
To enhance lighting, various mutli-texturing techniques are used ( like lightmapping ) and most recently, vertex and pixel shaders are used to make robust lighting ( See the article on microsoft's Driving directX column about Per-Pixel lighting. Search for it on microsoft's site, it's written by Philippe taylor )
As far as I know, these 2 APIs are the ones supported by today's hardware ( for graphics ).Quote:
One last thing, are there any other APIs other than DirectX or OpenGL. Those are the only two I have heard of because they are the most used in games.
There existed some other API known as GLIDE, which was supported by 3DFX's voodoo cards. It doesn't exist no more ( since Voodoo cards are taking their way to extinction )
For other multimedia features ( Input, Sound, networking, ...etc ) DirectX seems to be the leading technology on Windows. yet there exists some OpenML library ( I've heard of it , but I never used it. It could be still under development ).
Anything other than DirectX generally has the advantages of being :
1) Portable : Works on linux, unix,...etc
2) Non-microsoft'ish : A lot of people hate ( or at least don't like ) microsoft.
just have to comment on what a great community this is. the stuff that you posted are LONG.
Damn good post. 8 years later and I read this super high