What is a game engine supposed to be?
Author
Can anyone tell me what a game engine is supposed to be like? I have been making a OpenGL toolkit, GhostToolkit, but some friends think it is more of an engine than a toolkit. What do you guys say?
Quote:Original post by clayasaurus
If you can make a full fledged game with it, it is an engine.
So C++ is a game engine? ;-)
There's also the fact that there are many specialized engines. You can't make an entire game just using an "OpenGL Engine", you'll also need game logic, and maybe things like user input, sound, etc...
I think the terms "OpenGL Toolkit" and "OpenGL Engine" are largely synonymous. If I had to distinguish the two, I'd probably base it on how largely the underlaying API was abstracted. A toolkit might include utility functions that make managing display lists easier, while still having the user call glVertex3f to create them in the first place. An engine might in turn handle creating them as ell, from a file or similar.
Personally? When I have something thought out well enough and abstract enough for good reuse, I just and throw it into my common library (called "industry"), and just refer to said library as a library. Engine, toolkit, whatever, it dosn't really matter, it's all just semantics :-).
Screw y'all ASSEMBLY ALL THE WAY
mov ax, bx
mov bx, reg32
mov 00011010b, bx
call print ; already a function that is a couple 100 lines long :P
just kidding :P
screw this
C++:
cout <
mov ax, bx
mov bx, reg32
mov 00011010b, bx
call print ; already a function that is a couple 100 lines long :P
just kidding :P
screw this
C++:
cout <
Quote:Original post by Anonymous PosterIf your hand assembled text output function is several hundred lines long, you have done something seriously wrong.
call print ; already a function that is a couple 100 lines long :P
Quote:Original post by Anonymous PosterYou might want to take a look at some disassembly for the cout function. Then you might find a several hundred ASM lines print function..
just kidding :P
screw this
C++:
cout <
OP:
A game engine would be something you can "just" plug resources, scripts and such data bits into and it'd be a working game. If it has functions for doing specific things, but you still need to program the higher functions yourself, I'd consider it a library. Allegro and SDL are libraries. Torque, Ogre and Unreal Engine are engines.
A game engine is like the core of a game. It contains the core components needed such as audio, graphics, and user input and wraps them together to make the game playable.
To me a game engine is a series of governing systems that control and contain interfaces for repeated tasks. For example, rendering engine allows another system to ask it to draw something at a specific place. The calling system doesn't need to know how the engine accomplishes this task, it just needs to call something like
RenderingEngine.DrawObject(*ObjectToDraw*,*WhereToDraw*)
Another example would be an AI engine for pathfinding.
AIEngine.FindPath(*Start*,*End*)
And it would return a handle to the path it created.
It's basically the organized system that things have to go through to get the results they want.
RenderingEngine.DrawObject(*ObjectToDraw*,*WhereToDraw*)
Another example would be an AI engine for pathfinding.
AIEngine.FindPath(*Start*,*End*)
And it would return a handle to the path it created.
It's basically the organized system that things have to go through to get the results they want.
I agree with that, but there is a common belief, that Game Engine == Renderer. I don't know why people think that the only role of an engine is to draw stuff [and sometimes play sounds], and I can't understand why many coders call their Rendering Engine a Game Engine.
IMO a Game Engine is a group of various subsystems, not only rendering, but GUI, Sound, Input, Event Management, Resource Management,AI , Scripts, Config Files, Memory Manager, Task Manager, Logger, Garbage Collector and probably some more. Generally, a Game Engine creates it's own API, which is used by the real game. The latter can be plugged in a DLL [or the engine can be], and it uses only the interface provided by the Game Engine. This way your code is reusable and flexible, and the game itself is less likely to do weird stuff.
[Edited by - TeMPOraL on June 10, 2005 6:22:53 PM]
IMO a Game Engine is a group of various subsystems, not only rendering, but GUI, Sound, Input, Event Management, Resource Management,AI , Scripts, Config Files, Memory Manager, Task Manager, Logger, Garbage Collector and probably some more. Generally, a Game Engine creates it's own API, which is used by the real game. The latter can be plugged in a DLL [or the engine can be], and it uses only the interface provided by the Game Engine. This way your code is reusable and flexible, and the game itself is less likely to do weird stuff.
[Edited by - TeMPOraL on June 10, 2005 6:22:53 PM]
Traditionally these sorts of things are called Frameworks. We just happen to call it an Engine because it's cooler. Go figure.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
