what's a game engine?

I've read many articles on this topic but all they tell me is that the game engine is the reusable part of a game. Is it supposed to be a reusable code or is it a reusable executable file that you link DLLs to? Or can it be either? Some articles I've read tells me that the executable i open to start a game is the engine and when i google for open source engines, i get all these "GUI libraries" as I like to call then, like allegro, ogre, etc.
I have a basic idea of what a game engine is supposed to do but I'm not too sure how to go about writing one and what kind of things to include in it.

Well the engine of a game works like...uumm...well....the engine. It drives the game. It includes fundamental parts such as your class inheritance, the way the game is to handle animations, models, and other things. If you create your own file type that will be part of the engine and you will probably have some function to read your unique files. Are you getting the idea? Start by thinking about organization and classes. All the fundamental functions that your program will need to run the game. A good place to start is a movement system I think. One that people use a lot is the quake engine.

Quote:

---

Originally Posted by h_howee

I've read many articles on this topic but all they tell me is that the game engine is the reusable part of a game. Is it supposed to be a reusable code or is it a reusable executable file that you link DLLs to? Or can it be either?

---

I don't know what articles you've read. Was this amongst them?
http://en.wikipedia.org/wiki/Game_Engine

>>I don't know what articles you've read. Was this amongst them?
>>http://en.wikipedia.org/wiki/Game_Engine

no it wasnt. So those engines that came up in the search were graphics engines?

Graphics libraries I think would be a more appropriate name, but allegro handles things related to games other than graphics too says wikipedia. For future reference (don't even know how you missed it this time) use wikipedia.

Yeah those are more like graphics libraries than anything else.

A lot of general facts have been stated, which are all correct and helpful. I will try to give you a concrete example to work off of. I am actually currently working on my own game project right now, and I am being careful to keep the "engine code" and "game code" separate, so that I might be able to reuse the engine code in the future.

In my engine, which is still currently under development, this is what I currently have:

A Sprite class which handles any non-animated images that will be used in the project. An Animation class (which has along with it two other associated classes called AnimationData and AnimationManager) which handles all animations that will be used in the game.

There is also a tile engine, consisting of a Terrain class, which represents one piece of terrain on a game map (along with it is a TerrainManager), and a Map class, which handles all maps to be used in the gaming project.

I am currently in the process of building an entity tree/structure, which right now only consists of an Entity class, but will consist of more soon to come.

There is much more I need to do to complete the engine, but there are also many areas where I am approaching what becomes the border of the engine, and then we enter into the game code.

For example, as entities are on my mind of late, Entity is something generic that any game would need, and so it is engine code. However, a warrior or an archer are game specific entities, and should not be included in the engine, but instead be included in the game code. That is one concrete example of a difference between the two.

There are some aspects as well where AI might overlap. Much of your AI might be in the engine code, but there are certain aspects that are probably game specific. Pathfinding, for example, is probably something that will be on the engine side of things.

But anyways, that is my take on it. Hope it helps.

@DavidP,

"Manager" classes are considered bad. The methods and data of your manager classes should be static members of the class that they are "managing".

Thanks DavidP, that's just what i was looking for

btw, what's this manager class you speak of? What is it supposed to do?

Quote:

---

Originally Posted by h_howee

btw, what's this manager class you speak of? What is it supposed to do?

---

I'm not sure how DavidP uses his manager classes, but mine are basically classes that keep track of objects and entities. For example, I have a world class, and then a world manager that keeps a vector of worlds, and contains functions for creating and deleting worlds. I do the same with textures and shaders as well.

ah, ok
thx

Quote:

---

Originally Posted by pronecracker

@DavidP,

"Manager" classes are considered bad. The methods and data of your manager classes should be static members of the class that they are "managing".

---

I would agree with this in principle perhaps, except just for the heck of it, I'd like to throw something out here for people to comment on.

The Unreal Engine, for those that don't know already, is a game engine that starts up a virtual machine where the language of choice for it is a Java-like language call UnrealScript or UScript for short. UScript does not have static variables, interestingly enough, and therefore they rely on a lot of "manager" classes or the like.

http://unreal.epicgames.com/UnrealScript.htm

Quote:

---

Why UnrealScript does not support static variables: While C++ supports static (per class-process) variables for good reasons true to the language's low-level roots, and Java support static variables for reasons that appear to be not well thought out, such variables do not have a place in UnrealScript because of ambiguities over their scope with respect to serialization, derivation, and multiple levels: should static variables have "global" semantics, meaning that all static variables in all active Unreal levels have the same value? Should they be per package? Should they be per level? If so, how are they serialized -- with the class in its .u file, or with the level in its .unr file? Are they unique per base class, or do derived versions of classes have their own values of static variables? In UnrealScript, we sidestep the problem by not defining static variables as a language feature, and leaving it up to programmers to manage static-like and global-like variables by creating classes to contain them and exposing them in actual objects. If you want to have variables that are accessible per-level, you can create a new class to contain those variables and assure they are serialized with the level. This way, there is no ambiguity. For examples of classes that serve this kind of purpose, see LevelInfo and GameInfo.

---

Thoughts and comments?

Are manager classes a bad choice for a game engine? Should a game engine provide for better means of managing their data?

Sorry if this turns out to be a hijacking... ;)

Quote:

---

Originally Posted by pronecracker

The methods and data of your manager classes should be static members of the class that they are "managing".

---

I don't think I've even seen it done that way before. Not in a game engine anyway.

Without object managers you will have something just short of an object oriented disaster.

The goal of object oriented managers or more appropriately containers is just that. They contain and manage a set of objects. Using the container approach you would run every request and every action through the container first. No one else has permission to touch, alter, or delete the objects in the container except for the container. This means that all operations on objects are centralized and you know exactly who and what is creating/destroying objects and you also know when they are being destroyed.

Containers are a very good way to ensure you do not leak memory here and there since they alone are responsible for destroying objects. If you leak memory from a certain object or objects then you simply look in the container class to find out why it is leaking memory.

My entire system operates on this principle and while not the easiest to implement it does offer many benfits. In my system there is a base class that every object is derived from. If you understand COM programming you would understand my system. The base object class does next to nothing but implements a few base functions. The derived classes then perform the bulk of the operations on the objects they implement. Each container class is also derived from a base container class which implements basic operations such as adding and deleting objects as well as returning object counts. The derived container classes then begin adding to this foundation and implementing functions as needed.

I use managers in my game designs, whatever I'm making, from a text adventure to a fullblown 3d engine, managers or container classes as bubba said are the best way to do things in my opinion..

Generic manager class:

Code:

---

#ifndef RESOURCE_MANAGER_H
#define RESOURCE_MANAGER_H
#pragma warning(disable: 4786)
#pragma warning(disable: 64)
#include <vector>
#include <map>
#include <string>
#include <boost\shared_ptr.hpp>
#include <boost\weak_ptr.hpp>
#include <iostream>

template< typename T_ >
class Resource_Manager
{ 

public:

        typedef T_ value_type; // std library convention

        typedef boost::shared_ptr<T_> Resource_Ptr;
        typedef boost::weak_ptr<T_> Resource_Observer;
        typedef std::map< std::string, Resource_Ptr > Resource_Map;

        Resource_Manager<T_>() {};
        ~Resource_Manager<T_>() {};

        void Add_Resource(const std::string & name, T_)
        {
                Resource_Ptr Raw_Resource(T_);
                mResources.insert(std::make_pair(name, Raw_Resource));
        }

        Resource_Observer Request_Resource(const std::string & name)
        {
                Resource_Map::iterator  it = mResources.find(name);

                if (it == mResources.end())
                {
                        std::cout << "Internal program error, " << name << " does not exist!" << std::endl;
                }
                else
                {
                        return Resource_Observer(it->second);
                }
        }

        void Request_Resource_Removal(const std::string & name)
        {
                Resource_Map::iterator it = mResources.find(name);

                if (it != mResources.end())
                {
                        mResources.erase(it);
                }
        }

private:
        Resource_Map  mResources;
};

#endif

---

I use a templated approach to my manager, it allows me to store and dynamically allocate memory for a set of like objects. It works on anything from sound files, to 3d models, to simple menu chains.

I like it :d

Quote:

---

Originally Posted by h_howee

I have a basic idea of what a game engine is supposed to do but I'm not too sure how to go about writing one and what kind of things to include in it.

---

There are probably more opinions about what a game engine is/isnt than there are programmers. So heres my 0.02 worth:

A game application consists of three parts, The game engine, the application specific code, and the game data:

The game engine itself is the generic, retargetable code that handles the grunt tasks such as user input, menues, graphics output, sound etc.

The application specific code is the part of the code that handles things that are , well, specific to that game, such as weapons, spell effects, AI etc.

The game data is the stuff like graphics, sound effects, intro movies, weapon range/damage values, etc.

Generally, the game engine will only change when something like DirectX changes. The application code will change with every new iteration of the game ( Awsome Dungeon Romp v1.0 , v2.0 , v37.0 etc. ), and every update or bugfix. The game data will generally only change during bugfixes or playbalancing. i.e the BFS-9k does 200-300 slashing dmg, which is too weak, so you change it to do 300-400. No change in the code would be necessary.

use this for an example...

you get in your car and start roaming the streets...
the scenery flashes by your window... the faster you go,
the scenery goes faster...
you go around the block... soon the scenery becomes the
same as before...
a dog crosses your path (sprite)... you beep your horn...
using the curbs as your boundry so's not to hit a building...
unless you want that is... haha!
etc... etc...

everything pretty much becomes your engine... you program
different subroutines to cover, scenery, movement, sprites,
which all become invisible to you as you drive... they are just
there running... the variables would be pretty much your
location, and how fast or slow you drive... oh yeah! and the
dog's...