Hi Guys. Thanks for all your help from this amazing site, i managed to learn and understand OpenGL a bit better but i am still new to it however, my progress is evolving quite rapidly in OpenGL 3D Graphics programming. I have reached most of the set goals about learning OpenGL but i still know that i have a long way to go.

I just wanted to ask some questions that i am unsure of about 3D Game Engines. Here they are:

1.How would a rendering engine work like or be designed,would it have a set of classes that manage meshes and decides how they are rendered through a customized abstraction layer and what would be a bunch of good practices for creating a abstraction layer?

2.How Do Animations work? Mostly skinned mesh animations, are they in one file and are different parts of the animations organised in frames and to play a certain a animation, do you manually have to decide which frames you want to play in the application?

3.How would you handle input precisely? What i mean is how do you specifically program the input to work properly, would you use booleans to determine which key is pressed?

4.How are physics applied to a mesh? Is there something called a rigid Dynamic Body which basically is the same shape as the mesh and it covers collision detection and determines which part of the mesh collides with other objects?

5.How is it all combined into game logic? How would you combine 3D Graphics,Input,Sound and Physics together to create a playable actor?

6.How does a game loop work? Say you have a game loop and you call some events in the game loop, would you have to update the game loop everytime?

Any input would be quite valuable.

I can answer 2 questions even though I only worked with 2D games. These answers will apply to 3D games in the conceptual sense and should give you a better picture of how games work underneath the hood.

3.How would you handle input precisely? What i mean is how do you specifically program the input to work properly, would you use booleans to determine which key is pressed?

Input is commonly implemented using boolean to manage the "state of the key" along with keyListeners for button press and MouseListeners to make use of the mouse. Look into your API for keyPressed and keyReleased Event or something worded similar to it. In Java, they are called keyPressed and keyReleased which are asynchronous methods implemented in a class using an interface called KeyListeners. There should be something similar to that in the API you are using. In Java, you would need to add these keyListeners to the class that should listen to these key events which would be the graphics canvas. If you are using Java, there should be a opengl that works with Java.

A simple google search said Win32 will provide you with input functionalities for C++. This video should provide you additional information.

6.How does a game loop work? Say you have a game loop and you call some events in the game loop, would you have to update the game loop everytime?

It really depends on what the "event" is for. Input event is handled using event listeners. Collision logic can be written in class of the main character just to give you the big picture of your codebase and then needs to be refactored to a different class that handles or manages collisions in the game for organizational and good coding style purposes.

Game loop is essentially the "while loop" or I like to think of it as the inner loop of the game. Because not only do you have a game loop but you will also need to eventually implement a main loop which will be your outer loop when you start implementing main menu to game play transition. Back to game loops, Game loop is the "heartbeat" of your game that constantly does "work" for your game. The work it does is updates your game objects first and then draw your game objects every frame.

Each of your game object will be a subclass of a superclass you will write called Sprite class. Sprite class will have two methods called update and draw. Once you have your game objects derived from the Sprite class, you will need to override these methods because you want to implement "a specialization of what update and draw means to the game object it is tied to" because each game object will update and draw differently so they can act differently and appear differently in the game. The last part of what I said will become clear as soon as you are programming your game.

Your game objects would be created and then added to the list to be updated and draw every frame. And then have the game loop will do the updating and drawing on these objects for you into the game.

// this is a basic and simple form of the game loop when you are writing it. Eventually the condition "true" will need to be changed to "something else" because not only is there is a game loop but there is a main loop or outer loop for the game as I said earlier which handles transition from one state to a different state. For example from MENUGAME TO OVERWORLD. As a tip, it is a good idea to implement main menu to game play first because it will be that much easier to implement later on. I learned it the hard way...because I did the reverse.

while(true)

{

updateGameObjects();

drawGameObjects();

}

Hope this helps. It might seem like a lot of information right now. But stick with game development everyday and you will understand it that much better everyday. Best of luck!

1.How would a rendering engine work like or be designed,would it have a set of classes that manage meshes and decides how they are rendered through a customized abstraction layer and what would be a bunch of good practices for creating a abstraction layer?

First off, OpenGL and DirectX are merely a set of APIs that interface with the graphics pipeline. So a 3d engine basically begins by wrapping basic constructs of these APIs and applying layer upon layer of abstraction. For example, OGRE3D offers ways to create Vertex and Index buffers regardless of the rendering API being used since they abstract the DirectX and OpenGL API from the user. Then they offer higher-level classes to perform various things that are pretty common, such as a ManualObject to that wraps creating these vertex/index buffers and pushing them to the GPU. All a user of a ManualObject needs to do is feed the class the vertices & indices.

3.How would you handle input precisely? What i mean is how do you specifically program the input to work properly, would you use booleans to determine which key is pressed?

First off, Input is generally platform and language specific. Depending on the target platform and language, you'll basically have a wrapper that listens for input signals. You then need to turn those signals into some "state" which for keyboards is typically an array that is either 1 (pressed) or 0 (released). For analog type input such as a mouse, you'll need a bit more structure to how you store the state but inevitability it's similar.

The most important aspect with input is that you need to make sure that however you handle state, that you merely capture it and dispatch it at predefined points in the game loop rather than dispatching it immediately when it happens. This makes sure that state remains valid throughout a single frame rather than having some parts of your game behave as if a key wasn't pressed and other parts of the same frame seeing the key as pressed.

Keyboard and mouse events are captured whenever dispatched by the platform OS and the input system caches them. At the top of the frame, those events are dispatched to two important systems in the following order.

1. GUI
2. Action

This allows input that could be affecting the GUI (such as typing into a textbox) to get first dibs on saying the input was handled. If it was handled, input doesn't get dispatched to the other layers. If the input isn't handled, it gets dispatched to the action system where it can turn something like the 'W' key into a MoveForwardAction. Our input system also maintains an internal state table of these events at the top of the frame so that systems that would rather poll for input state (e.g. is key 'W' pressed or not) can do so and doesn't have to concern themselves with actions or events.

4.How are physics applied to a mesh? Is there something called a rigid Dynamic Body which basically is the same shape as the mesh and it covers collision detection and determines which part of the mesh collides with other objects?

I personally prefer to simply leverage an existing physics library and hook into their simulation step. Generally speaking, most physics implementations require that you first determine is your object a Rigid Body or Soft Body. Then you assign a shape to the physics object (box/capsule/sphere/mesh/custom). Then when the simulation is ticked, you can query the simulation to determine what objects collided versus which ones moved and update your own scene objects accordingly.

5.How is it all combined into game logic? How would you combine 3D Graphics,Input,Sound and Physics together to create a playable actor?

6.How does a game loop work? Say you have a game loop and you call some events in the game loop, would you have to update the game loop everytime?

There are usually two approaches to gluing these things together and it depends usually on the game's complexity.

For a simple game, a GameObject hierarchy that relies on inheritance will work just fine. You have some GameObject that you begin to split into things like a Player, NPC, Enemy, etc and go from there. But as your game's complexity grows, you will start to see pitfalls of this approach.

For more complex games, it's better to favor composition over inheritance hierarchies. You begin to decompose your game objects into bits and pieces of functionality. Then you construct your game objects as though they're a container of these pieces of functionality. If you read up on Entity/Component or Component-based systems, you'll start to get an idea of how powerful composition can be in a GameObject system over the traditional approach above.

Lastly, a program by it's very nature is a 'loop' of sorts, regardless of whether it carries out its set of operations a single time or repeats itself until some trigger constitutes that the execution must end.

In a game, this loop basically dictates an order of operations that must be done to initialize the game, the operations that are repeated over and over such as 1) gather input 2) update logic 3) render to the back buffer 4) swap buffers 5) perform post frame operations and lastly the set of operations to perform cleanup. Hitting the escape key is captured during step 1 and some system says hey set your game loop's stop variable. Then steps 2-5 happen and when the top of the loop checked the stop variable, it exits the loop.

Hope all that helps.

Thanks a lot guys. Your Input helps quite a lot especially with the input and physics. Also is is it a good idead to start with a low-graphic version of the game and try testing it on other PC's?

I still dont seem to know how 3D Animations work if you have a set of them and want to use them whenver you can.

Problem with the OP is that after writing a 800 pages book as answer there will still be some blanks. The more general the question the more differing answers you'll get. There is no right way, especially if you don't specify some goals / restrictions.

For a (IMHO) good general rendering solution look for the threads dealing with Frostbyte Rendering Architecture, rendering task/job queueing, and the therein linked threads.

For a (IMHO) good approach for input processing see the threads in the past half year where L. Spiro has written his answers. Short delay, no input misses, and input translation to abstract actions are the keywords in input processing.

For a (IMHO) more or less complete approach at animation look e.g. at tutorial about Unity's Macanim (especially on YouTube, because they give a good overview). Animation blending, animation layering, and multi-axis control are keywords here. Skinning is mostly a standard process.

The decision of what animation is played depends on the character controller (in case of a PC) or AI (in case of an NPC), which is a beast by its own. Decision trees are one possibility. There is also the AIGameDev.com site especially for AI.

For a (IMHO) good approach of game world organization look at component based entity systems (CES) with sub-systems for the logic. IMHO you should avoid scene graph approaches.

For a good explanation of what a game loop may look like try e.g. the book "Game Engine Architecture" by Jason Gregory; a belonging excerpt of it an be found at Gamasutra.

Most if not all of the suggestions above is for sure overkill for a newcomer, I know. The parts suggested above together make a fine, modern engine. For now they may be worth to be studied to get an overview of why people tend to try more complex solutions than necessary on the first look. But start simple. And please break down your future questions so that threads do not cover such a broad spectrum. It helps in giving and hence getting better quality answers.

@haegarr I am very serious about making a 3D Game so sorry if some of those questions are overkill and maybe too dificult to answer. What i am trying to build is a simple third person game with one actor and a terrain which i will use as a base for my game. I want to be able to get a career as a programmer in a game company.

My current targets are to:

-Understand OpenGL and 3D Graphics programming for games.

-Understand Physics in a game/Use a physics library such as bullet.

-Understand All aspects that go into a game.

-Understand Game/Game Engine Architecture.

-Program a simple third person camera persective simple game with one actor.

-Expand Techniques and Expierence of 3D Games to a more advanced level.

-Start an actual project using the pre-created base.

-Choose the genre for the game.

-Design the aspects of the game.

-Start Development.

Thank for your list of sources, they look quite helpful.

@haegarr I am very serious about making a 3D Game so sorry if some of those questions are overkill and maybe too dificult to answer. What i am trying to build is a simple third person game with one actor and a terrain which i will use as a base for my game. I want to be able to get a career as a programmer in a game company.

My current targets are to:

-Understand OpenGL and 3D Graphics programming for games.

-Understand Physics in a game/Use a physics library such as bullet.

-Understand All aspects that go into a game.

-Understand Game/Game Engine Architecture.

-Program a simple third person camera persective simple game with one actor.

-Expand Techniques and Expierence of 3D Games to a more advanced level.

-Start an actual project using the pre-created base.

-Choose the genre for the game.

-Design the aspects of the game.

-Start Development.

Thank for your list of sources, they look quite helpful.

You need to refine your target. First understand and then apply afterwards. If you try to understand of all it before applying it, you just make your life a lot more difficult than it needs to be. Start making stuff of what you learn immediately. Make mistakes and learn from them quick. It does not need to be complete or even polished on day one. Build test builds or prototypes of what you are trying to achieve.

@haegarr I am very serious about making a 3D Game so sorry if some of those questions are overkill and maybe too dificult to answer. What i am trying to build is a simple third person game with one actor and a terrain which i will use as a base for my game. I want to be able to get a career as a programmer in a game company.

My current targets are to:

-Understand OpenGL and 3D Graphics programming for games.

-Understand Physics in a game/Use a physics library such as bullet.

-Understand All aspects that go into a game.

-Understand Game/Game Engine Architecture.

-Program a simple third person camera persective simple game with one actor.

-Expand Techniques and Expierence of 3D Games to a more advanced level.

-Start an actual project using the pre-created base.

-Choose the genre for the game.

-Design the aspects of the game.

-Start Development.

Thank for your list of sources, they look quite helpful.

You need to refine your target. First understand and then apply afterwards. If you try to understand of all it before applying it, you just make your life a lot more difficult than it needs to be. Start making stuff of what you learn immediately. Make mistakes and learn from them quick. It does not need to be complete or even polished on day one. Build test builds or prototypes of what you are trying to achieve.

That is what i am trying to do. Understanding is a very vital skill to learn anything and with those targets i am not aiming to get day one perfect builds, and i am practical so the stuff i learn i actaully do because if you understand how something works but cannot implement it then you wont progress and it will be for nothing.

This is how i started learning and understanding OpenGL better:

1.Looked for tutorials for OpenGL.

2.Coded a basic triangle render.

3.Looked at the code.

4.Looked through each of the functions and used the OpenGL reference to see what those functions do and why they do them that way.

5.Re-Code the basic triangle with additional knowledge that i learned and try to see what else i can do and experiment with it.

So i know what you are saying and it is what i am already doing.

I'm not sure but i think making a game without an engine but with the libraries you mentioned is like indirectly making an engine because even though the aim will be to make a game, you will have to make these seperate libraries work together and once you are done, you may/may not have made an engine .

Pretty much true. I am aiming for a game mostly but if i build a engine while developing a game then i guess that would be even better.