what is an engine?
Author
Hi.
I'm writing this post because for a long time my mind was being disturbed by this question - what exactly is an angine? (doesn't matter if it's a graphic 3d engine or physics engine or whatever with 'engine' in it)
You see i've read many articles about making engines and many of them more or less were trying to explain what is an engine but I guess they failed.
Fellow programmers in my country were posting their works on a game development forum and they were saying that they are working on an engine, they were showing screens and source code cause they were sure it's what they called it... an engine. But some of those more skilled programmers told them that those works were just frameworks and not engines and they were not willing to answer my question or couldn't explain it...
...so the question is, what should a project have to be called an 'engine'?
what is a framework and how does it differ from an engine.
Regards
An engine is the supportive code that allows you to code the game itself.
Take asteroids for example. It's about shooting asteroids, it's not about loading models, lighting, shaders, sound... no, that is the engine's job, to create an environment where you can code the game logic.
So, the engine is the code that supports the code for the game logic.
Regarding the diferences between a framework and the engine itself, I think that an engine is made from many frameworks. One could say that a framework is an atomic part of an engine.
Take the Eiffel tower for example. Let's pretend it was built solely so that people had a great view of Paris.
So, the "engine" is the whole tower expect the top part, the "game logic code" is the top part, and a framework could be said to be one of the 4 legs of the tower.
Hope I made it clear enough.
Take asteroids for example. It's about shooting asteroids, it's not about loading models, lighting, shaders, sound... no, that is the engine's job, to create an environment where you can code the game logic.
So, the engine is the code that supports the code for the game logic.
Regarding the diferences between a framework and the engine itself, I think that an engine is made from many frameworks. One could say that a framework is an atomic part of an engine.
Take the Eiffel tower for example. Let's pretend it was built solely so that people had a great view of Paris.
So, the "engine" is the whole tower expect the top part, the "game logic code" is the top part, and a framework could be said to be one of the 4 legs of the tower.
Hope I made it clear enough.
An engine is like the core of your game. You can use different things like sprites, 3D models, sound, and so on. The engine controls how all of these things are controlled. Thus, your engine defines how levels are loaded, how sound is played, how to load in models, etc.
Author
hm...
so if I have an app which creates win api, inits d3d dsound or dinput and all of this stuff is divided into functions like for example 'LoadTexture()', 'PlaySound()' or even 'DrawQuad()' and other stuff needed to init or use all apis and I put all that into an .exe file, and then when I load from a dll file game logic functions like 'DrawPlayer()' or 'PrecacheData()' which use funcs from .exe... can I call it an engine?
i hope it's wide and clear what I have written :P
so if I have an app which creates win api, inits d3d dsound or dinput and all of this stuff is divided into functions like for example 'LoadTexture()', 'PlaySound()' or even 'DrawQuad()' and other stuff needed to init or use all apis and I put all that into an .exe file, and then when I load from a dll file game logic functions like 'DrawPlayer()' or 'PrecacheData()' which use funcs from .exe... can I call it an engine?
i hope it's wide and clear what I have written :P
I haven't dipped into engines at all yet during my learning experience. I have been wondering about this subject too.
So. An engine is composed of a ton of functions that you can use to build your game from the ground up? I've seen quote/unquote engines that are heavily GUI intense. Like a level editor for example. Would that be considered a part of an engine or just a "Tool"?
So. An engine is composed of a ton of functions that you can use to build your game from the ground up? I've seen quote/unquote engines that are heavily GUI intense. Like a level editor for example. Would that be considered a part of an engine or just a "Tool"?
An engine is also reusable. It should hopefully be modular and loosely coupled from the game so when you want to make another game, you could just take your "engine" and focus completely on the gameplay since your engine is already complete.
Quote:Original post by Prozak
It's about shooting asteroids, it's not about loading models, lighting, shaders, sound... no, that is the engine's job, to create an environment where you can code the game logic.
So, you could say the engine is the "how", while the game is the "why". (sorry, just felt a little philosophical..)
thopol: Yes, you can call it an engine, but understand that there is a diference between an engine and an API wrapper. If your "engine"'s sole purpose is to facilitate and automate the use of Direct3D, then it is a D3D wrapper, and not an engine in itself. An engine has to be more than a wrapper arround a specific API, be it 3D, physics, sound, GUI, etc...
ildave: If a piece of software is targeted mainly at working upon the resources, then it is a Tool, even if part of it uses the engine as a backend.
helix: Although I don't desagree with what you said, I also consider that an engine should be as reusable as possible, because you put so much effort and time into making one, but that is totaly optional. There isn't a written rule that says that if an engine isn't re-usable, then it isn't an engine. But let's examine this more closely. Why can't an engine be re-usable? The only answer I can come up with is when the engine code is too mixed up with the game logic code, or vice-versa, and you can't separate them apart, without causing the whole structure to colapse. That is bad design. The programmer cannot tell where the engine ends and the game logic starts. The two should be very clear and distinct entities...
ildave: If a piece of software is targeted mainly at working upon the resources, then it is a Tool, even if part of it uses the engine as a backend.
helix: Although I don't desagree with what you said, I also consider that an engine should be as reusable as possible, because you put so much effort and time into making one, but that is totaly optional. There isn't a written rule that says that if an engine isn't re-usable, then it isn't an engine. But let's examine this more closely. Why can't an engine be re-usable? The only answer I can come up with is when the engine code is too mixed up with the game logic code, or vice-versa, and you can't separate them apart, without causing the whole structure to colapse. That is bad design. The programmer cannot tell where the engine ends and the game logic starts. The two should be very clear and distinct entities...
IN MY OPINION...
The terms "engine" and "framework" are not offical or well-defined.
A car engine takes gas/oil/air and turns it into torque.
A game engine takes textures/scripts/input and turns it into fun! :)
A terrain engine takes heightmaps/textures/surface data and turns it into 3d terrain.
Etc.
A framework is just a collection of things that you can use to create other things. But a framework is not very useful by itself. For example, let's say I write a collection of classes that handle memory management, multithreading, filesystem i/o, network i/o etc.
I can then *use* those classes to create a game engine and a terrain engine and hello world or whatever other programs I can think of. But just having a memory manager and a networking strategy and a compressed filesystem is pretty useless on its own because those things don't *produce* anything (like an engine). But I would call the collection of those classes a "framework" because it provides the tools I need to quickly write full applications.
Make sense?
The terms "engine" and "framework" are not offical or well-defined.
A car engine takes gas/oil/air and turns it into torque.
A game engine takes textures/scripts/input and turns it into fun! :)
A terrain engine takes heightmaps/textures/surface data and turns it into 3d terrain.
Etc.
A framework is just a collection of things that you can use to create other things. But a framework is not very useful by itself. For example, let's say I write a collection of classes that handle memory management, multithreading, filesystem i/o, network i/o etc.
I can then *use* those classes to create a game engine and a terrain engine and hello world or whatever other programs I can think of. But just having a memory manager and a networking strategy and a compressed filesystem is pretty useless on its own because those things don't *produce* anything (like an engine). But I would call the collection of those classes a "framework" because it provides the tools I need to quickly write full applications.
Make sense?
In my opinion, an engine provides the base functionality of something else. For instance if I'm making a tetris clone, my engine would consist of the Initialization of the window(creating the window, sizing it etc...), initializing whatever api i'm using(SDL, DirectX, OpenGL). My game code is built on top of that, for instance, handling the falling blocks and doing the collision detection etc..
The engine doesn't depend on the game. I could use the same engine to create Breakout clones, space invaders or even a larger game. The game simply sits on top of it.
The engine doesn't depend on the game. I could use the same engine to create Breakout clones, space invaders or even a larger game. The game simply sits on top of it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
