What exactly is the difference between a library, a framework and an engine? These terms get tossed around, sometimes interchangeably, which can obfuscate some of the fundamental technology we use when developing a game. Today’s brief article strives to clarify the relationship between these three important terms.

Framework

Frameworks are the easiest to define. A framework is basically the structure that exists around your game. It is the skeleton inside which your game is built. Frameworks tend to be designed to optimize a specific task, and in doing so, enable the rapid development of an application (or game). Frameworks usually have an API that exposes some of the functionality provided by the framework. Frameworks tend to be authoritarian, dictating a certain technical design upon the application using the framework. Mini-game collections are a prime example of where a framework can prevent a great deal of headaches and optimize the development pipeline. In this context, the framework would likely provide all the sound functionality, the pre-game UI, score screen UI, score tracking, player’s game state, and possibly player’s achievements. Basically, anything that can be shared across the various mini-games would make a good candidate for moving up to the framework layer.

Library

Libraries are a collection of classes and functionality that will stand completely separate from the application code and solve a certain set of tasks required by the application. Where Frameworks are authoritarian, Libraries are subservient. If the Library is well designed, it’s typically possible to replace the Library with a similar one from a competing vendor. Libraries can be as sophisticated as a networking layer, but in general, Libraries tend to want to remain low-level in order to enhance reusability. A common type of Library is a Utility Library that provides a lot of basic low level problem solving.

Engine

An Engine is more authoritarian than a Framework. Engines are very high level, and are designed to solve specific tasks. They tend to be a giant black box in which a bunch of complicated functionality is hidden. They tend to solve the task they are designed for in a very particular way, and they tend not to play nice with alternative approaches to solving that same task. The task the Engine is designed to solve usually determines the scope and reusability of the Engine. Generally speaking, the cost of switching away from an Engine is much much higher than that of a Library, and much higher than that of a Framework. A Pathfinding Engine will require the data that is inserted into the system to be structured a particular way. It will expose functionality to perform pathfinding queries, but typically will be optimized for a certain type of data structure. A Networking Engine will likely abstract away a lot of the internals of the system, making it more difficult to optimize certain aspects of the Networking, but it will do so while possibly providing you with a slew of functionality for free, like buddy list support or game matchmaking. Oftentimes the monolithic Game Engine is designed to create a very specific type of game in a specific genre, and it is optimized to do so. A Platforming Game Engine might come with level editors, an entity management system, built in physics and networking, but it would probably be impossible to add deformable terrain if this is not a feature built into the core Platformer Game Engine.

Hopefully this discussion helped to clear up some of the confusion in these often abused terms. When you’re working on a piece of tech, keep your goals in mind and steer it in the right direction.

As an aside, Libraries tend to be the easiest of the three to build, BY FAR. If you’re wanting to develop a stable code base upon which to build games, start there. As time goes by, engines and frameworks will start to design themselves, but almost every project can benefit from a strong core set of Libraries.