When Is A 'Game Engine' NOT A Game Engine...

because of recent events (and lets not bring em down here), i'm just curious as to what you guys/girls think qualifies something as being a game engine...

i heard this and that referred to as game engines... some people refer to Blitz3D as a game engine... so far, i've only worked with two tools that i really consider to be engines... Torque, a game engine... and Irrlicht, a rendering engine...

to me, an engine, in its most generic definition, is something that when run, does some sort of work... if it can't be made to run, then it aint no engine...

i think that this definition can be applied to game engines as well... if you can run it, and it does some work, then it's a game engine... in other words, with minimal initialization, a game engine will run itself and provide a method for the developer to add his/her own customization to it...

as far as i see it, a programming language isn't a game engine... a library isn't a game engine... all of these are merely tools that coder can leverage to develop an 'engine'... but by themselves, they don't qualify... at least that's how i see it...

but maybe my definition is to narrow... what's your thoughts and opinions on this...

--Mike

..yup I do agree...game engine should be whole system for game creation, and when I said this I mean on tools builted on the top of the actual rendering engine...entity placement, VFX seting up, AI, physics set up, scripting/coding etc...this should be game engine...if we talking about Blitz3D itself, it cant be described as a game engine, since all things you have to do 'manualy' trough code, what means its most likely closer to be language builted around specific API, what Blitz3D is in fact..Torque, Unigine, Trinity, Unity , PR6 is a game engines becouse appart from ability to code your game, you can do all necessary perparation for your scene content/vfx before you start doing that..

Hmm... Years back when you wanted to do 3D, you licensed a "game engine". We used Twilight3D & Legus3D for several projects. These handled everything gamewise.

Today, "game engines" are rare, everything is broken down into individual "engines". You have rendering engines like Ogre, physics engines, sound engines. Often, Collision, AI, Multiplayer will be in standalone "engines".

With the way 3D games have advanced, it makes sense to split a game engine up so that it will be easier to port whatever you need to a new project.

I think "game engine" has become a term that is genericly applied to just about anything game related. ie, if you use B+, you write a "game engine" to handle the various aspects of your game and make it do what you want.

My opinion is exactly that. It may be what you *want* in an engine, and that's all well and good, but I don't want it, so by your definition, I don't want a 3d/game engine at all.

When you use your engine metaphor, with the made to run, doing work, etc, I'm inclined to think that what you're really looking at is the difference between an automatic and manual transmission. You want the engine to decide when to change gear and to do it for you.

I think this analogy holds true, too, because you sacrifice some efficiency when you do this. In much the same way that an automatic transmission doesn't give you the optimal gear changes, a 3d engine which controls all the rendering for you ( among other things ) doesn't give you the optimal speed. Now personally, I don't want the engine in control of that, I know what I've done in my game and it doesn't. So I am always going to know how the engine should work better than it should.

Perhaps this is related to your OOP thinking. You want everything abstracted to the n'th degree, and while there are benefits to this, there are disadvantages too. You lose a little speed and you lose a little flexibility. Sometimes it matters, sometimes it doesn't. Some people care, some don't. You weigh up the pros and cons and decide.

Now if you were using a game engine designed for very specific types of games, I'd have a different answer. If we were talking about an engine for making 2d top-down RPG's, I'd say fine, not much to lose by having it all done for you. But you're not, are you? When you talk about engines like Ogre, TV3D or Irrlicht, you're talking about very generic engines which are being used for a huge variety of games.

So the question becomes, do you want to use an engine designed for your game or designed for someone else's? Both answers are still valid, but with the above caveats that you must accept the loss of a little flexibility and speed. And it's not as though these engines aren't doing *anything* once you engage them, as you're proposing it. They're doing a lot. They're just not doing everything, and they're waiting for you to tell them when you want them to do it.

I want the flexiblity and speed. You want the abstraction and ease of use. Why should either of us be right or either wrong? Both types of engine are valid, just depends what you want.

not at all Gabe...

your analogy is very appropriate, as it'll help explain my point of view... your conclusions are wrong though, mostly because you failed to really look at the analog that you yourself presented...

in short, i just want the engine to have a transmission... i'll decide if it is to be a manual or an automatic... and i'll do the shifting myself...

that's the whole point of an engine... anything less, and you become the engine builder... or, in the analogy your present, you become the transmission designer... there is no engine there, you become the engine builder...

a game engine will already have a transmission available... the developer using that engine, will be free to decide what type of transmission... how many gears... and how and when it will shift gears...

anything less, and it's not an engine... just a collection of spare parts that an engine can be made out of... in the game engine context, a collection of libs that you put together to make an engine...

now some game engines do enforce a sort of restriction, like you said... Torque for example, is geared (no pun intended) towards fpsers... therefore, that transmission will most likely be an automatic by deafult, and you will have to go into the engine, and redesign it, so that you can have a simulation, or a RPG type transmission... but the transmission is already there... and that's what makes it a legit engine...

--Mike

I consider a game engine to be something that comes equipped with the tools (be them a GUI or via code) to create a game. You may have to improvise some of your own tools, but those improvised tools should be made from pieces of the larger work -- the engine, in this case. If you have to write new tools from the ground up with your own renderer or input engine or something like that, then it is no longer a game engine to me.

I mostly agree with Noel and Red. A Game Engine is the nuts and bolts with which you build a game. It is the games 'guts'. So IMHO something like Torque (a generalized interface that essentially exposes Tribes 2) and DOOM3 both qualify, where as Blitz3D does not.

Blitz 3D is not a game engine, it is a games programming language (3d at that).

A game engine to me is a specifically written software with system (or systems) to control and as Red would say 'run' those processes described within the design document brief. It could be written in any language, Blitz, C++, Flash, Director, Dark Basic...etc

If you need to include physics or other external control systems then there is a method enabling interfacing these components too.

The engine is not really the level designer, or the modeller or the graphics or audio design software, but in a crude sense it is the 'playback system' which enables the full brief of the game to happen.

The engine may be part of a bigger set of systems which include the other tools (or some of them), but to me the engine is the code which takes all the elements designed elsewhere and combines them to become the game. Making the sum of the parts bigger.

That's off the top of my head, and maybe slightly too simple a desription - but thats what it is to me.

IPete2.

I expect a game engine to consist of

[Edit] after reading Grey's post below I agree that (1) here is not really part of an engine, just a welcome addition.

1) The tools required to build levels including all of the lightmapping/bumpmapping and placement of enemies and objects etc.
2) The code which makes everything happen. i.e. it loads in your levels and everthing just works from the doors opening/closing to the ai of the enemies and the progression from one level to another plus saving/loading and running the game over a network.

A game engine is geared to one genre of game e.g. FPS

You can mod it by adding different textures/sounds/models/levels/music/scripts but you should not need to have to tell it how to render the 3D world or anything as low level as that unless you want to change something fundamental.

This is confusing.... however using Torque without re-compiling sounds like using an engine by this definition, but Torque lacking many tools required(most of them are left 3rd party softwares)

A Game Programming language gives more freedom to do things you want...?

I would say that an engine is the mechanics that make the game work. What you lot are talking about is more like a game workshop/studio for easily making a game that uses the engine.

there is a difference GA... compare Torque (a game engine) developer to a DOOM engine developer, to a FPSC ( a workshop game creator thingee)... all extremes of the definition, game engine...

one is a game construction set, and the other two are not...

on second thought though, there are also some striking similarities... so, i have to say that you are sorta right then...

i guess it all depends on the level expertise required as which one you choose to use... but yes, both of em are game engines...

all three run... they all allow for modifications... but a FPSC developer has a much less expected level of coding and artistic competency required than a Torque or DOOM engine developer...

hhhhmmmm... interesting points from everyone...

--Mike

Jake,

I agree.




IPete2.

IPete2: Oh OK, cool, I never got that far, sorry.

Hey no probs I was just backing you up dude! ;)


IPete2.

well I'm glad we agree seeing as recently we been discussing making an engine anyway! Otherwise it would be worrying :-)

> When Is A 'Game Engine' NOT A Game Engine...

when you think it isn't. really you could call blitz3d
a game engine if you wanted. it is a programming
language designed to help people make dx games.
depends how you classify game engine, dunnit?

I think it's an engine when you can modify it. If you're working on a car you can make it faster in the 1/4 mile or you can make it get better fuel economy. You can adjust it so it works well at high altitudes or in a dusty desert rally. An engine should already be capable of driving somewhere in one way ... and it should allow you to modify it to drive anywhere.

Blitz3D is a bunch of nuts, bolts, and assorted parts which you can form into an engine ... but it doesn't do anything without some assembly. Torque on the other hand already does the FPS game ... when you download it you can immediately play a game and then if you want you can immediately pop the hood and start adding the 'cold air iduction' and 'high flow mufflers', etc...

> I think it's an engine when you can modify it.

yes, that's what i was talking about. these people
who think that blitz3d is NOT a game engine are
missing the point. all programs that make it easier
to make a game are game engines, imo.

if you take a step back and look at what all these
"game engines" have in common, you'll see they
all provide a higher-level language to work in,
that's where i make my definition of "game engine"
ie. a program that provides a higher-level language
that is designed to make games.
blitz3d clearly falls into this category.

That's not what I meant. Unfortunately, you cannot actually modify Blitz3D ... in addition Blitz3D doesn't do anything on it's own ... there's no game pre-built in so it's definitely not a 'game engine'. Maybe you could call it a game programming language engine ... but not a game engine.

All a game engine is is a collection of tools and libs that allow you to make games. Most developers don't buy an off the shelf ready to use game engine. They create the tools and libs and then when they have their engine up and running, start creating the game. This is often a long and drawn out process that develops over time, much of the functionality isn't there at the start, and only comes together in the last 6-8 months as things adapt to suit a particular game. Some require more modability than others.

Only reason torque is easy to pick up is that it was built with MP and mods in mind. It definately is an Engine, but a lot of the nuts and bolts limit what you can do, and much of it would have to be rebuilt from the ground up to suit more varied games than FPS.

well, who DOES agree with me then? :)

Well that is true ... but still it's an engine. No one ever said it'd be easy to take a Honda 4-Cylinder engine and make it run 10's ... but somewhere out there someone did it. They probably had to tear it down and rebuild it to a degree but that's the point. The Torque Engine can be modified to do anything ... you just need the right leverage to turn all its bolts ... some of which are hard to reach ... but they're all there full exposed.

I think my philosophy with car engines and game engines is similar. Start with something that already hauls ass ... and then do a few simple mods to get the most out of it. Make it the best engine it can be without having to re-build it and you can have a real nice ride.