[Sayid Ahmed]

I thought I'd ask quite a basic question, because I always assumed I knew the answer to it but I never actually really thought about it. Wikipedia explains it as:

Quote

Game engines provide a suite of visual development tools in addition to reusable software components. These tools are generally provided in an integrated development environment to enable simplified, rapid development of games in a data-driven manner.

Let's say, hypothetically, I'm making an RPG. I download some game engine online that's suitable for that genre. it'll be open source, otherwise I have to pay for it. I then start making models, textures, sprites (or use some given in a library provided with the engine), mechanics, mapping, etc, whilst the game engine has already provided things such as the rendering of graphics, physics and collisions etc.

Is this analogy correct? Does this mean that most game devs (including indies) will use a pre-made engine to allow them to focus on making the actual gameplay? Does this also mean you're required knowledge on programming doesn't have to be as intense? how much harder is it to start from scratch?

[ButchDean]

I don't really think I agree with that definition of a 'game engine'. A game engine is the overall software that drives the software components that make up the interactive (and hopefully fun) software that we know as a 'game'. What that definition is referring to is most likely middleware from which games are built.

The Wikipedia link I think you are referring to pretty much explains it very well as far as I can see.

[Sayid Ahmed]

ButchDean, on 14 May 2011 - 10:54 PM, said:

I don't really think I agree with that definition of a 'game engine'. A game engine is the overall software that drives the software components that make up the interactive (and hopefully fun) software that we know as a 'game'. What that definition is referring to is most likely middleware from which games are built.

The Wikipedia link I think you are referring to pretty much explains it very well as far as I can see.

I scanned through that earlier So what I described is specifically middleware and not just an engine? what I'm still curious about is, if an engine is provided, other than making models and texturing and sprites, what else does the dev have to do?

[ButchDean]

Essentially the 'game engine' defines every functional and interactive element that forms the game. The 'middleware' provides a rich suite of available functionality that is available to the 'game engine' if used.

Middleware prevents us from reinventing the wheel with tried and tested solutions to problems in lower-level game programming.

What the game developer does is fashion the capabilities of the middleware in code to behave a certain way in the game as defined by 'events' or 'triggers' that accept parameters and behave accordingly.

As game developers we are effectively wrapping the middleware functionality in our own code to form the 'engine'.

Now, when we have our game engine as built on the aforementioned middleware we will have hopefully made the engine interfaces flexible enough to be used across several titles, hence the game engine reusability you speak of.

Game studios also make use of tools that facilitate the reuse of game engine components for artists and designers so that they are effectively not force to code in order to test their work.

Does that clarify matters?

[stayscrisp]

If you check out 3D engines such as Irrlicht or Ogre 3D you will see that there is still a lot of work to do to take these engines and make a game from them. These engines help to speed up development by wrapping up some of the more low level coding but there is still much to do after that; tying in middleware solutions is a great amount of work in itself

This post has been edited by stayscrisp: 15 May 2011 - 05:36 AM

[Sayid Ahmed]

ButchDean, on 15 May 2011 - 12:00 AM, said:

Does that clarify matters?

That was a very good explanation, thanks

[j_cart007]

Sayid Ahmed, on 15 May 2011 - 05:22 AM, said:

ButchDean, on 15 May 2011 - 12:00 AM, said:

Does that clarify matters?

That was a very good explanation, thanks

Game Engine is a software system designed for making video games. Game engine has developed by breaking down the tools access and structured to the extent that game engine has the potential of different modalities which enable a person from a non-programming background to make the game.

Game engine is often associated by development tools; these tools are usually streamlined visual tools to enable rapid development of games. Game engine is often named game middleware since they offer comprising and reusable software architecture to produce a game while cutting down the cost, workload and any former issues that may come about through the scheduled action plan in order to get the completed product.

[ButchDean]

j_cart007, on 15 May 2011 - 04:15 PM, said:

Sayid Ahmed, on 15 May 2011 - 05:22 AM, said:

ButchDean, on 15 May 2011 - 12:00 AM, said:

Does that clarify matters?

That was a very good explanation, thanks

Game Engine is a software system designed for making video games. Game engine has developed by breaking down the tools access and structured to the extent that game engine has the potential of different modalities which enable a person from a non-programming background to make the game.

Game engine is often associated by development tools; these tools are usually streamlined visual tools to enable rapid development of games. Game engine is often named game middleware since they offer comprising and reusable software architecture to produce a game while cutting down the cost, workload and any former issues that may come about through the scheduled action plan in order to get the completed product.

No, you're combining the marketing term for a game engine whereby you have companies selling ready-made components to hobbyists versus the more formal description where middleware is actually used to form the game engine.

[j_cart007]

ButchDean, on 15 May 2011 - 12:11 PM, said:

j_cart007, on 15 May 2011 - 04:15 PM, said:

Sayid Ahmed, on 15 May 2011 - 05:22 AM, said:

ButchDean, on 15 May 2011 - 12:00 AM, said:

Does that clarify matters?

That was a very good explanation, thanks

Game Engine is a software system designed for making video games. Game engine has developed by breaking down the tools access and structured to the extent that game engine has the potential of different modalities which enable a person from a non-programming background to make the game.

Game engine is often associated by development tools; these tools are usually streamlined visual tools to enable rapid development of games. Game engine is often named game middleware since they offer comprising and reusable software architecture to produce a game while cutting down the cost, workload and any former issues that may come about through the scheduled action plan in order to get the completed product.

No, you're combining the marketing term for a game engine whereby you have companies selling ready-made components to hobbyists versus the more formal description where middleware is actually used to form the game engine.

I do agree with u, as I'm not that expert like u but am I totally wrong in this scenario ?

[ButchDean]

j_cart007, on 15 May 2011 - 10:19 PM, said:

...

I do agree with u, as I'm not that expert like u but am I totally wrong in this scenario ?

Feel free to disagree with me even though I have the expert badge. No biggie!

If you wish to follow the marketing blurb where to them a 'game engine' is a set of features and assets that can be simply put together, more akin to a term like 'game factory' or whatever then fine. But if you want those familiar with game development to know what you mean then how I presented it will get you a favorable response.

[bensmiley45]

ButchDean, on 15 May 2011 - 02:45 PM, said:

j_cart007, on 15 May 2011 - 10:19 PM, said:

...

I do agree with u, as I'm not that expert like u but am I totally wrong in this scenario ?

Feel free to disagree with me even though I have the expert badge. No biggie!

If you wish to follow the marketing blurb where to them a 'game engine' is a set of features and assets that can be simply put together, more akin to a term like 'game factory' or whatever then fine. But if you want those familiar with game development to know what you mean then how I presented it will get you a favorable response.

I'm a mobile game developer and in my experience a game engine is a library which makes performing common tasks easier. They normally provide a suite of functions including: Graphics, Physics, Sound, UI, Particle effects, Scene management, Networking and maybe AI. For example, in Cocos2d which is the most popular iPhone game engine, to load a sprite into your game only requires three lines of code. To load a sprite into a game without the game engine would require over 100 lines of code. In this example the game engine is performing a lot of boiler plate code to save the developer time. I've written a more detailed tutorial on this topic What is a game engine?.

[Serapth]

Game Engine is one of those tricky terms, because it is relatively ill defined.

Even stayscrisp to a degree fell into the confusion trap by referring to Ogre3D as a game engine, which it isn't, but soley because that is how the developers choose to describe it.


Actually, Ogre is a very good example of what to look at in terms of defining what a game engine is and isn't. Ogre3D very much fits the definition many have chosen to describe what a game engine is, it's a framework, code and set of tools used to create a game. Well, that sounds pretty much like a game engine then, doesn't it?

So why then is Ogre3D not a game engine? Well, thats because of what it doesn't have. Ogre3D is essentially a scenegraph at heart, with a rendering layer on top of it. For those that don't really understand, a scenegraph can basically be thought of as the "data" that goes into making a game. When you add a polygon, render a scene, cull a portal or do various other activities, it is the scene graph where this magic happens. On top of that scenegraph with Ogre, there are the various renderers ( OpenGL, GL ES, DirectX ) that actually draw the scenegraph to screen. Of course, Ogre3D also handles animation, effects, cameras and the various other graphical tasks a game engine need to perform.


So then, what doesn't it do? Well, there is no native level editor ( although there are plugins/converters for many different 3D applications. There is no IO library, or audio library. There is no scripting library, or state server, or networking, etc... The lack of these components make Ogre not a game engine.

Now let's muddy the water a bit... do you need a network library or scripting language to be a game engine? No, not really. IO library... no, but then, I can't think of a single one that doesn't contain this functionality.


Where the line gets even blurrier is when you jump to 2D. What many people would refer to as a library I would consider a game engine. Are SFML or SDL game engines? Well, there is a complete lack of tooling, and without something like TileD or Mappy, there is no level editor. More importantly, there is no actual concept of a game in there... no facilities for storing or persisting data, no scenegraph or level loaders, etc. On the other hand, both SDL and SFML provide pretty much provide all the functionality you need to create a game. There are audio routines, display routines, io routines, networking routines, etc... Pretty much all non-game related bits. Are these libraries ( plus Corona, Love and a few thousand other comparables ) game engines? I guess that depends, you could argue it either way.


If you look at a game engine as a piece of technology that provides all/most of the underlying requirements of making a game, then yes, these are game engines. If you on the other hand, feel the distinction is in providing the ability to author a game ( full level editors, game entity management, etc... ), then no, they aren't. I personally don't know where I stand on this divide, it's not so clearly cut as it is with 3D products.


Middleware is another wishy washy term that comes from the land of marketing speak, so it has very little definition. Essentially and "add-on" ( as in, not provided by the OS, like GameKit, or DirectX ) library that you slot into your code could be considered middle ware. Renderware ( a previously popular game engine ) was considered middleware, and won a number of awards for being such, but that doesn't mean it wasn't an engine, it very much was! Again, some of the most common "middleware" applications in use today, for example Blink, PhysX/Havok or FMod are all certainly middleware, but then, they are all also simply libraries as well. So what makes something a library vs middleware? Not a damned thing, one can be one, or the other, or both, or neither.

In the end, constructs like middleware and engine aren't really strongly defined, although they certainly have a common meaning. If you want to consider SFML or Corona an engine, go ahead, you won't specifically be wrong, although you certainly may not be right to some people.


One other thing, going back to the OP.

"it'll be open source, otherwise I have to pay for it."

I very much don't like that sentence for many reasons.

Disconnect the concept of free and open source, they are different. Something can be open source, but require you to pay ( many popular libraries are available open source, but require a monthly fee to use their build servers for example ). On the other hand, many closed source projects can be available in a free form, such as UDK or Unity. Finally, being open source doesn't completely shelter you either, unless you have the capability and capacity to maintain your own fork, something many(most) people DO not have. In this case, you are to a degree at the whims of the project and people are getting increasingly screwed in this regard. The AirPlay ( previously free and open ) SDK got popular, then got spun off into the commercial Marmalade library.

This post has been edited by Serapth: 07 May 2012 - 09:10 AM

[ButchDean]

bensmiley45, on 07 May 2012 - 05:51 PM, said:

...

P.S. The link I posted didn't work so in case anyone is interested it's: http://www.deluge.co...s-a-game-engine

Had a read of your article, and although it is okay it has some inconsistencies and/or misinterpretations. I also feel more like it is an introduction on how to program games on iPhone (because of the use of Objective-C in the code snippets), and a mention of Android. Anyway, let's see what I have a problem with. I explained my thoughts before but let me reiterate with a focus on your article.

What is a 'Game Engine'

the article didn't get across the fact that a game engine is simply a superset of of the other subsystems that execute audio, graphics, AI and other routines. Where the confusion comes in is how to design the overall software architecture that clearly defines these discrepancies. In general, the game engine is able to perform every task in running the game by interacting with its subsystems and managing their intercommunication, for example when physics are resolved the new data needs to be passed to the graphics subsystem/engine to update position and perspectives, as well as provide input to the audio system to make a noise associated with a collision taking place, for instance.

Features provided by a game engine

As I pointed out above, the 'game engine' is a superset of its component subsystems, so if you remove audio you have a game engine that doesn't support audio, remove graphics and you have a game engine that doesn't support audio or graphics. As absurd as that sounds it is still a valid description. So my point is that the game engine itself is not an entity independent of its subsystems; the game engine is defined by its subsystems.

Graphics

I'm surprised you didn't clarify where making API calls ends and development of the actual graphics engine begins! Likewise for sound.

Physics/Particles Emitters

Firstly, particle systems ARE part of the physics engine - as well as anything else that is in motion in the game, even the camera employs physics! Remove physics from a game and nothing at all moves.

Also, all you had to say was that game physics engine employ Newtonian Dynamics and for the more advanced ones, Fluid Dynamics. There is no need to simulate quantum mechanics since no game requires simulation to that level, and there are too many unobservable phenomena making it impossible to simulate is a game. An example being how would be simulate dark matter in a game world? It can't be done.

Quote

Working these things out yourself is very difficult and would require a minimum of a degree in Maths of Physics.

Where on earth did you get this from?! I'm a physics and graphics programmer with my degree in computer science (although it was very heavily mathematical).

User interface

Is that an engine? Really? It plays no part in the actual gameplay logic or experience - hence the reason why it is normally called a 'front end'.

[Grigan]

@bensmiley45 Accurate, but a little complicated.

If you allow me, I would suggest this article. In a rather simple way, as I see it.
http://www.gamecaree...t_is_a_game.php

[bensmiley45]

Hi ButchDean,

What I was trying to do with this article was give a grounding in what a game engine really is from the perspective of a developer. There are lots of articles which say: a game engine is a series of APIs which shields the developer from the base level hardware libraries... This is a fine description for someone who's already an experienced developer but not much use for a beginner. I wanted to give a practical example of the kinds of things a game engine does and why it's useful.

From my experience the physics engine is usually separate from the particle engine. Mainly because particles only simulate a relatively limited range of "physics" actions. They don't collide so there's no need for collision detection and or force resolution. Particles normally just have a velocity, an acceleration and a rotation. I'm sure this would depends from engine to engine.

To design a physics engine you need to have studied advanced dynamics and linear algebra. Mainly for the collision detection. They don't teach that in schools so you need a technical degree. Maths, Physics, Engineering or Computer Science. I didn't write an exhaustive list but anything highly mathematical would do. My friends at university who studied computer science didn't study much maths but that probably varies from university to university.

The game engines I've used all provide support for user interface creation - again, I'm sure this varies from game engine to game engine. This falls within the very general definition of a game engine which is "a series of APIs which make the task of game programming easier". Because the definition is so general it would include a whole range of functionality. I did say in my article that I hadn't covered everything just the main areas to get started. Thanks for your replay, it's interesting to get different perspectives.