The Game vs The Game Engine? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

I was wondering if somebody could tell me how the game and the game engine fit into game development. Specifically what I mean is, the game engine does not actually have a game. So where I'm unclear about is basically, do game developpers build an engine, then create a new class that inherits from engine which becom开发者_JS百科es the game?

Ex:

class ShooterGame : public Engine
{
};

So basically i'm unclear on where the game code fits into the engine.

---

The distinction between the game and the actual game engine is architectural. The game logic is specific for one game whereas the game engine is something that can be reused. Much like an operating system provides utilities for applications the game engine does the same for the game code.

Game engines will typically have different APIs for:

• Loading multimedia data like audio, textures, 3d models
• Providing a game loop and firing off various events caused by the users input
• Networking
• Graphics rendering and various techniques to make the game look nice using lighting, particle effects or bump mapping
• Audio
• Artificial Intelligence
• An API to allow for defining game rules, game play, and game logic

Most game developers do not write their own game engine. It would be too much work. Instead they'll reuse a game engine their company has or license one. For first person shooters, id Software, and Unreal are two popular choices.

Once they have the engine they have to start writing code to make their game. This is done using the API provided by the game engine. For example Valve makes developers use C++. If you wanted a monster you would extend off of the Entity class and define how this monster behaves in that base class.

I would recommend reading through the documentation and tutorials provided by the various game engine providers. Keep in mind some games are classified as "mods" and some as "total conversions." Typically, a mod does not change the engine of the game and the total conversion may add or remove significant features to a game engine.

Here are a few sources I would recommend:

• http://developer.valvesoftware.com/wiki/SDK_Docs
• http://udk.com
• id Software releases their game engines as GPL after a few years. Reading through their code you'll learn a lot: ftp://ftp.idsoftware.com/idstuff/source/quake3-1.32b-source.zip. I would also recommend taking a look at Enemy Territory which was a based of quake 3 code: ftp://ftp.idsoftware.com/idstuff/source/ET-GPL.zip.

---

Actually, I can not tell the difference between engine and framework. It's just two different names.

What really odd is that game engine is all about client side, it seems like you do not need a server framework, whereas pure socket is enough for it.

But the reality is not like this, at least, there should be some framework like rails or django to ease your server development. Not to see game server is harder than web development in scalability, broadcast and other areas.

There is a commercial solution called smartfox server, and a new open source solution called pomelo framework, I've tried both, pomelo is much better. pomelo.netease.com is its home.

---

It also depends on the "level" of the Engine. What I mean with that, is how abstract the Engine is from a certain gamestyle. There might be small things like a engine that is focused on a FPS might be built to be optimized for indoor areas, outdoor areas, that you fly at high speed. So even if a Engine might not be locked to a game, certain game types will be easier to implement certain Engines.

But as stated above, the game won't inherit the engine, it will more probably draw on it's functionality, and you will probably attach components to it's existing components. Or expand the components that are part of the engine.

class CoolDiscoLight : public Engine::Light
{
};

...
//and somewhere in the source

"CoolDiscoLight cdl = new CoolDiscoLight etc..."

EngineInstance.AddLight(cdl);
...

Even more probible is the fact that just by extending from light and overloading the correct functions the light will be accessible to a level editor etc so you won't actually create them trough the source at all.

---

A game engine is generally consider the code that can be pulled out and replaced with out changing the game it self.

Like has been stated already, how exactly you USE the code of an engine depends on the engine it self.

Commonly, you will instance class from the engine library and use them. The way you do this will be dictated by the engine.

Some might provide more features then other, some focus on module-ness.

Often an full game engine, will just tie together various sub engines, such as a graphics engine that handles actually drawing to screen. A physics engine for simulating your game world. a UI engine for the UI and menus. a network engine that handles entowrking things.

The 'game engine' may well have these components built in directly, or it may just be wrapping another engine/library so that you use it in a similar way to the rest of the engine.

---

do game developers build an engine, then create a new class that inherits from engine which becomes the game?

It depends. Most of the time developers will make uses of existing game engines but sometimes they won't due to non-existence of wanted effects.

I have tried a number of different game engines. Most of them are behaving like this:

1. Defining sprites and sound elements by extending the class of it's basic entities
2. Defining groups for the ease of management
3. Defining a room or world for interaction between IO and the sprites
4. Program the logic in common functions like "update()" (the function will be called per frame)
5. Modify the entrance of the program to get into the first "room" or "world" (it can be a menu)

So a game engine is mainly do jobs of defining how the screen should display in a middle-layer, and the developer no need to worry about issues like will there be too many sprites loading outside the view-port? or When I press a key, where should the callback be located?, `Are they entity collided?" but focus on the higher level logic of the game.

---

Well I have been searching for game creation help and have found that an engine is the base of the entire game like the player creation is made easier as well custom graphics and physics or similar items. You also need to think of the next couple games that you plan to do and use the engine to build very little into your game which is already built for you.

If you want to learn what a game engine is, how if functions, or want to build one here is how is should go.

• GLFW - For opening an OpenGL window. It's a great little C library that opens windows on pretty much anything. Which is great because that's one less thing to worry about.

• GLEW - Managing OpenGL extensions. If you're gonna do OpenGL, there's really no getting around this one.

• Lua - Scripting. Although not yet used in my game, it's pretty much the go-to language for scripting in the industry because of its fast virtual machine implementation.

• Protobuf - Managing external state. You can find a documentation it here. The short of it is that you could use protobuf wherever you'd normally use XML.

• Qt - For standard containers and string manipulation. you don't need to use the entire Qt set of libraries, only the QtCore one. This gives you access to QList (std::vector), QHash (optimized std::map), QString (std::string with multiple encoding support) and lots of other goodies. Part of the reason you should go with it is because the documentation is superb.

• GLM - Math library. If you just want math in your game, this is the library for you.

• freetype-gl - Text rendering. It's a very well-written library for rendering text in OpenGL, you could do a whole lot worse.

• libRocket - GUI library based on HTML and CSS. It's great when you just want a UI on the screen, but gets problematic if you want to add animations.

Find the list here

These are great ideas for an engine just combine the libraries and build the game off of the engine you build from theses although it will take you sometime to finish if you dont have a fine team. Also I have read over this list and many others and this is the best 2d list. Also you don't need to build an engine UI because you only need the basics of the engine and build a separate project for each game. Here is how to do it right.

• Engine.h
  • enginepart1.h
  • enginepart2.h
  • enginepart3.h (ect.)

(use .h not .cpp for engine because you can not reference engine.cpp but you can reference engine.h) after building that

• Game.cpp
  • gameresources.h (resources include referencing Engine.h)
    • gamepart1.h
    • gamepart2.h (etc.)

And build the engine in a fashion like this but not 100% like this would be optimal

• Framework: Math, Random, Utility, Asset, Network, Window, Graphics, Audio, ...
• Player: AbstractPlayer, Score, Input, Collision, Reaction, Skill, Inventory, ...
• Map: AbstractMap, Area, Town, NPC, ...
• Enemy: AbstractEnemy, Creep, Boss, BaseAI, FuzzyAI, ...
• State: IntroScreen, MainMenu, LoginScreen, Game, PauseMenu, ...
• Interface: Button, Text, InputBox, ...

Found this here

Build it like this kind of

• Framework: Math, Random, Utility, Asset, Network, Window, Graphics, Audio, ...
• Entities/Characters: Player, Enemy NPCs, Friendly NPCs, BaseAI ...
• Map: Map/Level Editor (if you want), Map Objects (can be placed here), Special Map Features, ...
• State Control: Intro Screen, Main Menu, Logic Screen, Game State, Pause Menu(s), ...
• Interface: Button, Text, Input Box, ...

---

it often likes this

class ShooterGame
{
  Engine anEngine;
  public void Run();///run the world here
};

---

Yeah, what they said. I'd add though that game engines are usually designed for a style of game. A flight simulator needs are very different than Quake. Games like Oblivion are merging those needs together though, so this may soon not be the case.