Engines
I've seen many posts on engines and such I was just wondering what exactly they were and how you can make them. Thanks.
P.S Any tutorials?
An engine is a (dummy definition here as your looking at one :-) ) a processor that controls everything in a program. For instance a Program Engine might have input processing, output processing, image processing, text processing , and the list goes on and on in games there is sound,game,lighting,networking,input,graphics, sometimes including particle. So this makes it easy to make a game you just start an instance of the program engine class ie. EngineClass myengine; followed by anything else your game wants if it wants a graphic there should be something to load a graphic. Engine in my opinion is a very loose term and can be anything you want it to be.
EDIT: as far as tutorials go I believe there is a couple of articles on engine creation here. In the search box (top right hand corner) type Engine and you should get some of the gdnet articles. There are many books on engine design theory and unless you are a hardcore programmer designing an engine should be left unatempted until you fully grasp all of the features of a programming language.
Hope this helps,
Durfy
EDIT: as far as tutorials go I believe there is a couple of articles on engine creation here. In the search box (top right hand corner) type Engine and you should get some of the gdnet articles. There are many books on engine design theory and unless you are a hardcore programmer designing an engine should be left unatempted until you fully grasp all of the features of a programming language.
Hope this helps,
Durfy
a game engine is just a library of code,
function and objects that help you go from a api to a game
the api usually only has methods for basic drawing of images on screen and such, some examples would be win32 api or sdl
the role of the engine varys depending on how complete and specialized it is.
it would probably let you place sprites in a world and move them around and handle the drawing and things like scrolling and collision detection.
EDIT:
i dont think there are any tutorials on how to make a engine, but basically you make a game, if you can separate the code into a reusable library of helper functions and such that are separate from exact details of the game but used by it you have a engine
function and objects that help you go from a api to a game
the api usually only has methods for basic drawing of images on screen and such, some examples would be win32 api or sdl
the role of the engine varys depending on how complete and specialized it is.
it would probably let you place sprites in a world and move them around and handle the drawing and things like scrolling and collision detection.
EDIT:
i dont think there are any tutorials on how to make a engine, but basically you make a game, if you can separate the code into a reusable library of helper functions and such that are separate from exact details of the game but used by it you have a engine
I highly recommend that you read Game Engine Anatomy 101, which is an interesting, non-technical read and deals with this question at lengths.
Engines are peices software that help make games.
You don't really have to use an engine to game a game however. You can think of game engines like Operating Systems for games.
The point of the operating system is to provide a layer of abstraction to the hardware. It does a lot of things for you so as a program writer you don't have to worry about how to actually access the hard drive or share time with other programs.
The point of a game engine is to do a lot of things like timing, scene management, maybe config files or logging.
There for when making a game you can just worry about what you want things to look like and how you want them to behave instead of having to worry about coding where it should attach to the scene graph and such.
Making an actually robust flexible game engine is a ton of work. If you are interested in making games then there is absolutely no need to make your own game engine. There are many mature engines out there that allow you to make what ever you want.
check out:
irrlicht
You don't really have to use an engine to game a game however. You can think of game engines like Operating Systems for games.
The point of the operating system is to provide a layer of abstraction to the hardware. It does a lot of things for you so as a program writer you don't have to worry about how to actually access the hard drive or share time with other programs.
The point of a game engine is to do a lot of things like timing, scene management, maybe config files or logging.
There for when making a game you can just worry about what you want things to look like and how you want them to behave instead of having to worry about coding where it should attach to the scene graph and such.
Making an actually robust flexible game engine is a ton of work. If you are interested in making games then there is absolutely no need to make your own game engine. There are many mature engines out there that allow you to make what ever you want.
check out:
irrlicht
I'm guessing that your probably not familiar with Object Oriented Programming, or OOP, but simply put, game engines are like the building blocks of a game. If you decide to code a game, starting from scratch you will have to code a lot of stuff before you can see anything on the screen (especially with DirectX I hear), and even then it is a lot of work to get all facets of games working.
Coders spend a lot of time writing graphics/system/sound/input/memory code before they necessarily make something game related. So game engines are like half games. All the parts work, but you have to come and make them do things.
A similar analogy made here is true as well, because people who make cars dont really have the time or the know how to design very bit of circuitry, engine part or interior piece. Instead they may choose to buy their speedometers from a company that has dedicated their research to them. As long as it works, they dont need to know how
Coders spend a lot of time writing graphics/system/sound/input/memory code before they necessarily make something game related. So game engines are like half games. All the parts work, but you have to come and make them do things.
A similar analogy made here is true as well, because people who make cars dont really have the time or the know how to design very bit of circuitry, engine part or interior piece. Instead they may choose to buy their speedometers from a company that has dedicated their research to them. As long as it works, they dont need to know how
simply but, the game engine is the backbone of the game. it lets you have a set of code that is used to at the very basic, create the window with out haveing to write all the code for it.
if you write a lot of games its better to have an engine then haveing to re-write all the basic stuff all over again every time.
if you write a lot of games its better to have an engine then haveing to re-write all the basic stuff all over again every time.
Im surprised no one posted this yet
As others pointed out, an engine is the backbone of a series of games.
It can hide system dependencies, plugin APIs, file codecs, memory management,
video/input/sound interfaces, logging, etc. The engine provides the interface
(and abstraction) from system dependencies, and API specifications.
Game engines can also provide systems and routines common to games:
A*, particle systems, mabey common collision detection routines?
Because engines are an interface layer, you can create multiple games
using the same engine. (You dont need to worry much about the engines code,
so you can focus soley on the game itself, rather then file loading,
DX/OGL, portability, etc..)
Hope this helps!
As others pointed out, an engine is the backbone of a series of games.
It can hide system dependencies, plugin APIs, file codecs, memory management,
video/input/sound interfaces, logging, etc. The engine provides the interface
(and abstraction) from system dependencies, and API specifications.
Game engines can also provide systems and routines common to games:
A*, particle systems, mabey common collision detection routines?
Because engines are an interface layer, you can create multiple games
using the same engine. (You dont need to worry much about the engines code,
so you can focus soley on the game itself, rather then file loading,
DX/OGL, portability, etc..)
Hope this helps!
I believe it is just an abstraction of underlying code that accomplishes alot of the detailed tasks you'll likely use in a game.
For instance --
Imagine you have a racing game.
You may have an engine programmed that lets you simply say:
accelerate.
break.
turn 10 degrees to the left.
shift into 3rd gear.
You may not want to deal with how the engine handles those things, you just want to call them and have it do it.
You can reuse your engine in the future but change up all the other aspects of the program and have a game that is similar in style and the way it plays, but still has alot of unique features.
For instance --
Imagine you have a racing game.
You may have an engine programmed that lets you simply say:
accelerate.
break.
turn 10 degrees to the left.
shift into 3rd gear.
You may not want to deal with how the engine handles those things, you just want to call them and have it do it.
You can reuse your engine in the future but change up all the other aspects of the program and have a game that is similar in style and the way it plays, but still has alot of unique features.
I believe if you're asking what an engine is you really shouldn't worry about how they are made. Learn the basics first build your way up :-) I've never made an engine before. I've made reusable classes for things but never a huge monster of an engine.
-durfy
-durfy
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement