Game Engine vs. A Game Library

General Discussions
#1

I’ve been working with a guy for several months on a project we’ve been calling a game “engine”, but after all this time, we’ve kind of realized that we don’t know what distinguishes an engine from just a library.

Slick2D and libGDX are game libraries
JMonkey3D is considered a game engine

What exactly makes the difference? From what I can understand, an engine is pretty much a framework that you just build on top of/modify. Something like Yii or Django, in terms of web dev.

A library is just a set of classes/utilities you can use?

If an engine is just a framework, what part of a typical game is locked into the framework that would restrict your freedom of development? (Based on the idea that frameworks usually lock you into a certain implementation method of what you are doing)

Since, for libraries like Slick2D and libGDX, you generally just extend some sort of Game class and build around that, what makes them not an engine?

Thanks for any clarification in advance.

#2

I’m not exactly sure what you’re after, but I see a game engine as something that is build on top of a library. Something that makes it a bit less “low-level”.

Not sure if that helped at all, but. :stuck_out_tongue:

#3

The difference between a game engine and a game library is the core question. The extra stuff after that is just some things to consider when answering the question.

And by your definition, an engine is just a library that abstracts another library. Which honestly, I’m not going to say is false, as I wouldn’t be asking the question if I knew. But, I have to feel there would be more to it than that.

#4

You could have a look at this thread, it has some good points.

#5

I guess it can be considered just a matter of semantics, but I have actually separated my code-base into two sub-projects, called - you guessed it - library and engine.

As you suggest, the ‘library’ consists of the common building blocks that could be used in any application, such as: VBOs, texture loading, input handling, networking, model loaders, shader management, etc. (building on top of LWJGL in this case)

Whereas the ‘engine’ is slightly more application-specific and builds upon the library to provide stuff such as (for example, if we’re building a fantasy MMO) terrain/level management, day/night cycle, weather, etc. If you were building for a slightly different genre (say space games) then you may well create a different engine adapted to that genre, but would still re-use the same library (VBOs are VBOs whether its an MMO or space game).

In turn one could then take an ‘engine’ to create (to follow the example) a fantasy MMO game using the facilities it provides with little or no further coding, just design and config. In fact this is way that most games companies work, not many actually develop their own engines, they tend to buy or lease off-the-shelf products that are optimised for the type of game they are aiming for and then configure/design the game using editors and other tools.

Some ‘engines’ are so powerful and comprehensive that they could be used for just about any application or genre, e.g. Unity, Unreal 3, etc.

However ultimately it’s your baby so you can call ‘it’ what you want :wink:

  • stride
#6

In my opinion, a game engine is just the product of what you build over a game library, in most cases.

a game library is the backbone of the engine that the developer creates. I could make an amazing physics engine based off of libGDX, for an example.

#7

Platform = Same API for different hardware and OSs
Engine = Multiple Libraries
Library = like minded API abstractions

#8

I always called libgdx a “framework” - hey another term =D

well its just terminology for the most part, but in libgdx most of the low level opengl command are all still suable, if you want. I’m not sure your typical engine has that.
on the other hand I’m sure Unreal engine has that… well whatever

#9

In my humble opinion, JogAmp is a set of low level bindings with a few helpers, LibGDX is a middle level library, a framework, a tool kit. It helps you to write games but you can write an engine with it. Jagatoo is a library used in the 3D engine Xith3D. JMonkeyEngine is a game-oriented 3D engine but not a game engine because some key aspects are missing (AI for example). You can write a game engine with a 3D engine. For example, JClassicRPG (a game engine for RPGs) is based on Ardor3D which is a generalist 3d engine. You can write a WYSIWYG editor with a game engine. For example, JFPSM is based on my own game engine which is based on Ardor3D.

Have you tried to create a game with JMonkeyEngine? It is very helpful but there is still a lot of work to do even though its integrated game development environment is nice :slight_smile:

Edit.: I ported the JOGL backend of LibGDX to JOGL 2.0 some months ago (Xerxes helped me), that’s why I’ve just mentioned JogAmp, it’s not off topic.

#10

i personally think that the main difference is that a game Engine is a full software that “doesn’t” require anything to be launched, it also has it’s own IDE for compiling and debugging and building, and the goal is to make the development more easier than usual by providing a “casual” user interface.
In the other hand, a framework or library (aren’t they the same :stuck_out_tongue: ? ) is a bunch of classes that will also make the development a lot easier since their main role is to provide us with the “basics” tool to develop a game.
So in my opinion the main difference is that an engine has it’s own UI while a framework don’t .
another thing,
mostly all the good Libraries are open source and free ;D

#11

Pretty sure engines don’t all have IDEs, although I agree that it is more “full” of a software type. Engines also don’t necessarily have UI.

#12

Library: Rendering Code, Image Loading, Sound Loading, basic things that you need to get started with a game.

Engine: Skyboxes, Model Loader, Terrain Loader, all of that expected stuff built on top of the Library.

#13

A library usually provides an interface for a specific subsystem or component that you might want to integrate into your game: image loading, audio loading/playback, physics, rendering, and so on. A game engine provides the plumbing that ties all of those subsystem/components together (using several existing libraries, a bunch of custom code, or a mix of both) and usually provides access to it all via a framework. In short, a library is something you can use to implement the different systems of a game, and engine implements the systems for you in order for you to get busy with the game code and not worry about all the plumbing.

Technically, an “engine” is still a library. But that keyword lets you know that its doing a lot more for you than just loading images or playing audio. And you still might have a “rendering engine” or an “audio engine” that provide a lot of goodies on top of basic graphics/audio APIs. For example, OGRE isn’t a game engine, but a rendering engine–nobody calls it a “rendering library”–because it does a heck of a lot of work for you than just abstracting away the underlying platform and rendering APIs.

#14

So, pretty much the consensus is that a library gives you functionality for something particular like image loading, audio, etc. and an engine is built on top of several libraries to give you all that functionality in one place.

Which brings me back to why Slick2D or LibGDX is considered libraries, when they technically provide the ability to implement most aspects of a game without the use of additional libraries.

And on a slightly different note, keeping this on a 2D graphics level, what is it that is happening when an engine is built from several libraries? As far as I can tell, you could just dump several libraries into a single archive and call that an engine with no additional code.

#15

You’re overthinking what’s very much a loose terminology with no hard and fast definitions. A library is chunks of code. An engine does stuff. There’s no final authority on what makes for which.

#16

It’s not that I’m over-thinking it, as much as I’m interested in the topic. I know there are several nuances and discrepancies that really fudge the line between the two. But, I’m just forming a more concrete separation for my own endeavors and understanding.

#17

There is a lot of gray area between Engines and Libraries in Computer Science. But, I think there is a slight difference between the two that hasn’t been covered.

A library is a series of items (in this case, code modules) that can help you perform many different tasks very well. Slick2D is a library because it isn’t suited to just helping you do one specific task. You can use it to produce anything from games, to applications, to other more powerful tools.

An engine is a series of items (also in the case, code modules) that help you perform one task very well, with limited support for the other things. Engines will actually focus on a particular item, such as 3D lighting, 2D platforming, or a specific game look-n-feel.

The reason there is a lot of confusion and it is so abstract is that engines contain libraries, so they technically are a library in itself. They get all the benefits of the libraries they soak up, but they are also able to cater to a genre much better than a library.

So to put it bluntly,

A framework/library is a group of code that has tools for a variety of tasks.
An engine is a library/framework that caters to a certain genre more than anything else. Like gaming, 2D, 3D, tile-based, etc.

#18

My suggestion is to think more about how to code than what label to stick on it.

#19

100% agreed. Its also the “is a tomato a vegetable or a fruit” kind of deal to be honest. To one group of people an engine is a set of tools to create games with while to a whole other group of people it is something that needs to be upgraded yearly to magically get better graphics.

#20

Well, that suggestion isn’t really on topic. It’s just a question. It’s not something that’s keeping me awake at night. I’m sure if there was something you were interested in, you wouldn’t appreciate if someone told you not pursue the topic.

Yes, and that’s why I made this thread, so I can understand how other people thought of the matter, to get a pool of opinions, and weigh them against each other for a better overall definition (for myself). I understand that which is which and what does what is almost purely semantics. I’m not looking for someone to step up and just lay down what’s what. I’m just interested in the subject, that’s all.