|
I started explaining to a friend of mine how a game is designed in layers. I wanted to make sure I explained things correctly to him so I wanted to verify my thoughts here. Basically, the way I understand it:
is built upon each other in that order. Is this correct? Am I explaining this right? |
|||||
|
|
Everytime someone uses the word "engine" in relation to a component of a game, the word loses a little meaning. The term was invented in the Doom days; imagine how much meaning it has left. Right. Not much. "Game engine" used to have a well-defined meaning. Nowadays, "engine" is just an overblown synonym for "library" or "module". The "Rendering engine" is nothing more than that part of a codebase which is told where to draw stuff, and that stuff gets drawn there. The "Rendering engine," in a well-architected game (hard to come by, I know) has no knowledge of who tells it what to render or where to render it. All it cares about is doing the rendering. The "Physics engine" is again simply the part of the codebase that decides how things move around and whether they collide. It should not know or care how this information is conveyed to the user. A well-architected physics engine should not have any particular dependencies on the rendering engine, or even know that it's feeding a rendering engine. It just moves stuff around. The "Game engine" is a concept so nebulous as to be non-existent. A "Scripted game" (one of these things is not like the other) is a game that has scripts that control some aspect of it. Which aspects is up to the game developer. Some games expose the renderer directly to the script, thus coding most of the game in the script. Others only expose basic things like the ability to spawn entities at fixed, predefined locations to scripts. Most are inbetween. Obviously, some don't even have scripting to begin with. Ultimately, none of these modules needs to have any relationship to one another. They can be said to be hierarchically composited, but none of them needs to know that the other exists in order to do their jobs. |
|||||||||
|
|
This screen from Game Engine Architecture (ISBN 1568814135) provides a pretty good overview on what components you may find in a typical game engine. |
|||||
|
|
I'm not sure you can explain it in terms of layers. A game engine has a lot of components, some of which you mentioned, but they are interconnected in several ways. First of all, #3 in the list is pretty meaningless I think. Second, Rendering and Physics may or may not be directly connected (most of the time the renderer depends at least a little bit on physics for object placement, etc.), and they may or may not be controlled by a custom scene manager. This also involves controlling the scripted entities. I would say the components are equals that act mostly independently but can access each other's data if they need to. |
|||
|
|
|
Well, not quite. The process is not necessarily so linear, and what you have listed here is mainly what is required from programmers. Depending on requirements, some of these things are not necessarily needed. Rendering engine is needed for 2d or 3d games, but for games that only rely on sound or some peripheral device output or such it might not be needed. Physics is not necessary for a broad range of games. Game engine is something that sits on top of the architecture and is compiled. Scripting is not absolutely necessary for games, and most games do not have any scripting support. Scripting is to avoid having to recompile on every small change, which will help, but for smaller games the compilation times may be so negligible that it doesn't matter. The order in which these are built not necessarily strict. But since "Game engine" is essentially on top of the structure, it is beneficial to have the interfaces of the graphics engine and physics engine consistent during the development. Usually you would use existing solutions for graphics and physics, because the available solutions are generic enough, usable and robust and it saves a lot of time. What you have ignored to mention here is that you need a lot of assets created too. Sounds, music, models, textures, maps, items, etc. depending on game. |
|||
|
|
|
Not really layers, more like parts. There is part that deals with drawing to the screen. Another part deals with collisions. Another part deals with physics, that is, how objects get moved around in the game. Another part deals with sound and music. Another part deals with input. Another part deals with in game events. Then there is the part that contains all of the actual game content; IE the enemies, items, whatever that makes the game. You could have another part solely dedicated to AI. All of these parts have jobs to do. Ideally, they don't care who is talking to them. All they care about is doing their job. They get something, process it, then spit something out. They don't care who sent it to them or where its going. All they care about is their job. A game engine could be considered all the parts that are not the game content. The game content would be the assets specifically unique to a particular game; the art files, sound files, music files, and code files that get processed by the other parts into output on the screen. They are two halves of a whole. |
||||
|
|
