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 librariesJMonkey3D 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?

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.

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.

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

Slick2D and libGDX are game librariesJMonkey3D is considered a game engine

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

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 ? ) 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

"It's not at all important to get it right the first time. It's vitally important to get it right the last time."

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.

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.

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

The distinction is subjective, there is no hard objective distinction.

Generally, a library does something more localized, where an engine or framework has a much broader usage.

I might use a library for math functions or collections or cryptography for localized tasks and the project can generally swap those in/out without dramatic effort.

An engine or a framework generally implies more broad usage. Multiple libraries, and more tight coupling across the project code base.

In my eyes. A game library contains things that a user can use to make a program such as usfull assets. A game engine is more of a prebuilt structure you build ontop of that already works on its own without implementing anything else.

I suggest that the destinction is in dependency, but not one's dependency on the other. I mean that if your code is a library, you could take it away from its "engine" counterpart and it would still be usefull, EX : a geometry library, or math library. But if you take this code deemed the library away from its higher level "engine" code, the engine would not be usefull.

But :Is an engine still an engine if it is unspecific to a genre of games?Is an engine still an engine if it is being implimented by another "engine", or is it now a library?Isnt it all just code anyway, all of it relying on the code lower than it?

I think a library handles a single utility such as graphics, audio, or networking, and an engine comprises of all the utilities. But if you think about it, you include a library, whereas in an engine, you would include primarily resources(scripts, graphics, audio, etc.).

So I think the proper term for all the engines being made around here are more like frameworks, where you provide a set of tools and utilities and people will fill in the holes(sort of like a hybrid between an engine and a library?)

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org