Remember last Friday's post? I had commented something about game engines, right? Ok, this is the first part of a small series of posts regarding game engines and other components like: game frameworks, game-oriented languages and game-oriented middleware.
As soon as you try to join the game industry you will run over a bunch of software components which may help you build a videogame from scratch, to some extent. Are all of these components a "game engine"? Quick response: "No". Why not? To answer that, let's first take some due notes of the following concepts:
- Game Engine: a software component that provides the core functionality that will help you implement "the whole" programming areas of the videogame.
- Game Framework: a suit of robust software and tools that offers a set of rapid and standard solutions to common program requirements and problems, all related to videogames.
- Game-Oriented Language: a language specifically built to let you program videogames with ease -or at least, (a bit) easier/faster than by using "general-purpose" languages.
- Game-Oriented Middleware: a software component that provides the core functionality that will help you implement only "a part" of the whole programming chain of the videogame.
By doing so, they usually bring at least one implementation layer between your final game and "low-level" libraries (like "DirectX" or "OpenAL"); generally speaking, "low-level" libraries provide access to computer/console hardware through a set of basic functions: take for instance "Application Programming Interfaces" (API) like "Direct3D" or "OpenGL", which can be considered as software abstractions of the "Graphic Processing Unit" of videocards (GPU), thus letting you handle and build "rendering systems".
Please, bear in mind that those 4 concepts are just one general and simple way of categorize the software components that you may find out there. Meaning, you could bring more categories to the field, rename or re-arrange the provided ones, but the important thing is that you realize that when you start to move down "the logic tree" trying to narrow general/base concepts, specificity may be found, and in turn, new categories may appear.
For instance, "Middleware" could sound too misleading for some since the word it-self wouldn't necessarily imply that it deals with just a part of the game-programming chain (contrary to "the whole"), but it'd imply that it brings at least one layer between your game and a low-level API (thus, some could deem "1" and "2" above as more general middleware).
Again, it's up to you to build your basic list of categories and place each component within them either with a great amount of certainty (for "obvious" choices) or "at a rough guess" (for "not-that-obvious" ones).
1. Game Engines.
If you remember one of my previous posts, when you want to program a video-game you will have to deal with lots of main logic areas: Rendering Pipeline, AI, Physics, Scripting, etc.
Game engines come at a hand to such purposes. They bring programmer-friendly solutions, methods, and techniques which will let you face the task of implementing each logic area according to the program requirements of your videogame.
In other words, a game engine will provide you with the proper software components so that you can program the core aspects of your game in a rapid and reliable way. This doesn't mean that you will press some button and, say, the physics of your video-game will be "auto-magically" programmed for you. Following the physics' example, it means that you'll have a group of pre-built functions that will help you set the proper physics' behaviors for your video-game, but how you assemble the puzzle is your Company's task, you team's task or your task.
What kind of game engines can be found? Well, basically there are 3 type of engines: (a) general-purpose engines, (b) game-type-specific engines, and (c) game-bound engines.
(a) General-purpose engine: offers a set of functions so that you can develop and program any type of video-game.
(b) Game-type-specific engine: offers a set of features so that you can develop and program a certain type of video-game. For instance, a "First-Person-Shooter" game (FPS).
(c) Game-bound engine: created for a particular "title" -or series. Its use is normally considered as "one-time" even though sequels of the game may appear, which use a modified version of the base engine.
Most of the (currently available) game engines were developed to be use with C++ language, which is the standard language for game development (alias, the language used by 99% of each and every "Pro"). They are usually deployed as a set of "dynamic-link libraries" (DLLs), or add-ons to the most-used IDEs (like Visual C++, Dev-C++, etc.), so that they can be easily referenced, integrated and used in your game's implementation.
Sometimes, it's curious and instructive to see how these engines have evolved during years. One may think that it all starts with a general-purpose engine and then everything moves in a top-down direction. Makes sense. However, one may go wrong sometimes ...
For instance, GarageGames' "Torque Game Engine" was originally designed for the game "Tribes 2". After that, the engine went public so that developers could use it to build "Tribe-like" videogames for a minimum price which varied as a function of the kind of licenses offered.
Since then, the engine has been modified in such manner that today is one of the most used multi-purpose cross-platform game engines among "indies". What is more, it can be considered a game framework since it offers a whole set of tools that help developers leverage the production pipeline.
Therefore, GarageGames' TGE moved along the whole range of types of engines, starting from "(c)" and upto "(a)".
2. Game Frameworks.
"A suit of robust software and tools that offers a set of rapid and standard solutions to common program requirements and problems, all related to video-games". Meaning?
Game frameworks usually go beyond than game engines do, in the sense that they not only provide the libraries you need to carry on programming tasks with ease but also bring a set of tools into play which help you develop parts of your game in a graphical manner.
By the use of "Graphical User Interfaces" (GUI), the developer enjoys a more controlled experience over areas of programming and design, generally resulting in a more comfortable interaction with game APIs. Although it cannot be always assured that desired results are reached thorough the only use of GUIs, some frameworks also offer the possibility of either using scripts to do a fine tunning of the final output and/or extend the game logic, or accessing the final source code before compilation.
Some years ago these frameworks only consisted of either an add-on to existing languages (the game engine) plus a game-level editor to create new levels for your game. Now-a-days, they have evolved to more complete systems formed by several tools which offer more features so as to produce more accurate results with less lines of source code manually inputted by developers.
Levels construction, pre-calculation of lights and shadows, creation and visualization of meshes and animations, setting of game characters and their respective behaviors, general rules for the game (like collisions and physics), integration of cut-scenes, shaders, music and sound, ... these are just a few elements in the list of features offered by top-most game frameworks.
3. Game-Oriented Languages.
What is the difference between a general-purpose language and a game-oriented one? Simple. With the former you can usually program any kind of software -limitations may appear depending on the language. Take C# for instance, with it you can implement from graphically-appealing applications to console command-type programs. With the latter, only video-game related software can be produced -some exceptions do exist, where multimedia applications can also be created.
Does this mean that I can only use game-oriented languages to create a videogame? No, you can also use general-purpose languages -like C++, C#, Visual Basic and Delphi- by plugging in add-ons, class libraries, game engines and or game-oriented middleware, where available.
Why using then a game-oriented language? That is a matter of assessment, resources and preference. These kind of languages offer their own syntax, commands and structure. Not all of them follow the Object-Oriented Programming Paradigm (OOP) and some of them sometimes consist of a wrapper of a base API (like DirectX) with some moddifications and additions to ease the user experience.
What is the difference with "scripting"? A script is interpretated at runtime. Game-oriented languages usually provide a compiler that converts the source code into machine code at compilation time. Also, many of these languages provide an "Integrated Devleopment Environment (IDE) which consists at least of an official source-code editor.
Should I choose an OOP-tailored language? Again, that is a matter of preference. Some may still find some comfort on using non-OOP languages, but believe me, once you start to understand OOP and appreciate the advantages of OOP languages, you'll use OOP and you won't want to turn back the page again.
4. Game-Oriented Middleware.
Contrary to the criteria that leads a component to be considered as a "Game Engine", this kind of middleware specializes in a certain "logic area of incumbence" of the game-programming chain. For instance, AI.
There is a new growing wave of enterprises that specialize in the production of middleware components that one can "hook" onto their game projects. One of the main advantages of this components is the strong set of features they provide plus a high grade of reliability. One of the "cons" is simple, the more number of components you use in your game project, the more difficult will be for you to assemble the puzzle and follow the evolution of each component. Moreover, performance hit should be monitor closely since using a great number of external components does not necessarily mean that performance will increase, a priori.
The main areas covered by game-oriented middleware are rendering, physics and artificial intelligence. But new specific solutions to general problems are appearing from time to time.
Again, like "game engines" do, game-oriented middleware is generally targeted to C++ market. Some wrappers may exist for other languages/technologies, though, generally provided by third-party enthusiasts. Therefore, if used in a project, these wrappers should be always used with caution, having analized the whole spectrum of options.
Ok, I have read carefully the 4 points mentioned above, but what should I consider so as to choose the proper game components for my game project? Good question: it will be covered in next posts, but here is a short list: price, licenses (royalties, terms and conditions, etc.), support, bugs, average period between updates, performance, features, target platforms, type of deployment/integration, type of files supported (for images, meshes, animations, etc.) and so on.
"I've read your interesting post but I cannot wait for the next 'part' of the series, so where can I find more information about game engines and such?". Impatient, uh!? Ok, you can then pay a visit to "DevMaster.Net" site, where you will find a very extensive and detailed database of engines -most of them ranked by users.
Soooo ... with these words we are reaching the end of this first part about game engines and others. I'm not sure so far but I guess this will turn out to be a three-part series. ETA for "Part 2"? Maybe next Monday ... but as usually said "it will be released when it is done" ... ;)
[We will continue to discuss game engines on later posts, focusing on some of the existing/upcoming engines for .NET]
