Game Engine Architecture

Jason Gregory

Mentioned 14

This book provides readers with an in-depth exploration of 3D game engine architecture. It covers state-of-the-art software architecture principles in the context of game engine design, investigates the subsystems typically found in a real production game engine, surveys engine architectures from actual shipping games, and explores how the differences between game genres can affect engine design. Topics covered include large-scale C++ software architecture in a games context; engine subsystems including rendering, audio, collision, physics and game world models; multi-player engines; tools pipelines for modern games.

More on

Mentioned in questions and answers.

I am looking for resources that describe, in detail, the design decisions involved in game engine architecture. I am especially looking for analysis of the pros and cons of different design decisions at the lowest levels of the engine. The ideal resource, for example, might compare an inheritance-based object hierarchy to a flat, component-based object hierarchy. Or it might compare an in-engine editor with a separate editor tool.

What I am not looking for is a tutorial on how to implement any particular decision -- I would rather have a resource that discusses why to implement a decision.

Are there any blogs or books out there that offer this kind of insight into the game engine design process?

David Eberly's books (Game Engine Design) (Game Engine Architecture) go into great detail in this area. They are packed with info and do not hold your hand, which I think is what you're looking for.

For web references, check out

I have a rather over-analytic book. I think that the approach followed, is of writer's personal point of view and not of common knowledge, but I find it rather a good one to embrace the initiatives for your own try-out.

3D Game Engine Design, 2nd Ed.: A Practical Approach to Real-Time Computer Graphics

I would also highly recommend reading the various Intel articles posted on Gamasutra, or going directly to the source (Intel Visual Computing).

This, in my opinion, is one of the best, and most relevant to contemporary engines, articles: Optimizing Game Architectures with Intel Thread Building Blocks.

For a book, Game Engine Architecture by Jason Gregory is wonderful. It's simple, to the point, goes over the predominant issues in contemporary engineering, looks to the future, and uses Unreal and Ogre3D examples everywhere.

Finally, check out Game Architect.

Hope that helps!

Is there any reading material you would recommend on the subject of game engine development? Specifically 2D engines.

I've read up on SDL and I want to get started programming some games but I find myself a bit overwhelmed by the whole thing and I don't have a clear picture of what needs to be done. I just end up building complex, inefficient, rube goldberg programs.

Is there a book written on the subject that walks you through popular game engine designs or something along those lines?

I have these 2 books in my wish list:

Taking account of the Amazon comments, they are very good books.

(if I was going to buy only one that would be the "Game Coding Complete")

My game engine consists of a range of loosely coupled modules, which can be loaded and unloaded.

Some examples are: The base module, handling window management and responding to OS events, entity manager, Lua manager, physics manager.

Right now, these modules are organized as namespaces, and their state is defined through local variables in the respective source files. Each of the namespaces has an Open(), Close() and Update() function.

Now, I don't really like the solution with namespaces anymore.

  • It's not flexible enough

  • Even if it might not be needed in reality, having the plain ability of creating multiple instances of a module seems proper

  • It seems like I'm not making use of OOP here - a module base class with a virtual Update() member function would sound more reasonable

  • It's harder to ensure that when the module is closed and reopened, all of the variables will be reset too (A class with constructors and destructors would be easier)

  • You can't properly have the modules managed without explicitly calling Open(), Close() and Update()

So, my idea would have been to use classes for each of the modules, derived from a module base class. The module class instances would be handled by the ModuleManager class, which updates them.

But the solution with OOP brings up the problem of how the modules should communicate. Right now, the base module told the console module to print something via console::print()

  • How can I work around this problem without having to use something like g_ModuleManager.GetConsoleModule()->print()?

  • How could this module manager work in detail?

And my final question:

  • Do you have any further tips for me on the topic of writing a modular game engine in C++ with OOP?

  • Are there any design patterns that could help me in this situation, or maybe even concrete reading material?

Namespaces become very inflexible very quickly.
One way to keep things loosely coupled is to use messaging through a central message dispatcher; rather than saying console::print you would say messenger->sendMessage(PRINT_MESSAGE, stuffToPrint).
The console would register itself as a listener to PRINT_MESSAGEs and act the way it wants to. The sender doesn't need to care whether someone's listening, and there could even be several listeners to each message (useful for debugging).

Regarding reading materials, Jason Gregory's "Game Engine Architecture" is pretty good, discussing the pros and cons of several architectures.

I want to write a simple 3d game engine for apply. I have bought some vital Books like :

I am reading them, but I need a Road Map. please give me some advice. thanks.

I would recommend first building at least a small game using an existing engine so that you understand what an engine is from that point of view. Personally I'd recommend Unity, NeoAxis or UDK.

Then focus on building a game without without such an engine (as others have recommended). You might want to start by using some existing sub-systems like Ogre3D a slowly replace these with your own.

Then you'll be in position to start thinking about how to make an engine that's suitable for other games.

Jumping straight in to building even a simple engine is a bit like trying to write a novel without having ever read one. (And actually, novels are pretty simple compared to game engines.)

Of those books, I'd pick Game Engine Architecture and go right through it, rather than flip between different books. Use the others just for additional points of view, at least for now.

I'm a web developer and I'm trying to create a game. After some research didn't really find any kind of definitive Design Patterns for games except the State Based (which seems to be what everyone does).

People talk about the Scripting in games but I simply couldn't find a good resource for that, or better yet, a good example of running code.

I checked out Lua and Groovy but I'm kind of lost on how do I use those scripting languages integrated with the base code of the game.

Any help is appreciated (books, sites, etc.)

There are various ways to support scripting in games; it's a sliding scale.

On the one extreme, you can have practically everything running using the scripting language, so you define all of your data, logic and so on using the scripts and just have some core engine functionality in C/C++. In this scheme, nearly everything on the C/C++* side is just on that side of the divide to make it efficient enough, or because it's already been written in that language and would be costly to reimplement.

On the other extreme, you can have most of your game code & data defined in C/C++ and implement bindings and or callbacks to allow some customisation via scripts. Bindings (e.g. LuaBind) allow your scripts to get and set values / call functions that aren't defined in the script code, but on the C/C++ side. Callbacks allow scripts to listen in for game events being triggered; .e.g you may have a script that is invoked when an entity is about to take damage. You can then customise / extend your game logic via scripting.

The book Game Engine Architecture does a good job of explaining the possiblities, though it doesn't include sample code or anything like that.

The how of scripting is very much dependant on what your implementation style is and which core & scripting languages you choose. If you want something more concrete, try homing in on some language choices (e.g. C++ & Lua) and then track down some tutorials like this one.

The why depends on the approach taken, but it's generally to split gameplay functionality / behaviour / data from the guts of your game engine. This makes it easier to change since you can reload scripts at runtime without rebuilding the rest of the project. A nicely implemented scripting system also makes it easier for people to get involved or to mod/extend the game without bothering a programmer.

A concrete example:

You might want to build a piece of functionality that tells a player how much damage they dealt over the course of a round.

If you do this on the C++/core side, it means getting a programmer to put in a load of very specific code to serve a very specific function, rebuilding the whole project and deploying a new version. They then check with a designer that everything is grand. If it's not, they have to recode and rebuild, sapping lots of time.

With a well designed scripting system, it's just a case of dropping a round_damage.lua script into a scripts folder. The script is automatically hoovered up and activated when the game starts, and each time a player takes damage, the "OnDamageReceived" handler is triggered. When the round ends, the OnRoundEnded callback is triggered and the script displays a message.

Providing a rich set of hooks is exposed, a scripter can do all of this without a programmer's help. If they make a mistake or want to try something else, the scripter can immediately reload the script without shutting down the game.

*Note, I say C/C++ for the core engine stuff because that's the common choice, but it could be any language that's fast enough for your purposes.

I want to learn the basic concepts like collision detection, rendering and others in a general way (keeping the library usage minimum). I believe that once my basic concepts are clear, it would help me in learning different libraries easily, like OpenGL, etc.

I know without libraries it will take long time to build things. I am doing this for learning so I don't care about productivity.

I would love if the solution is using JavaScript (HTML5 Canvas) or C/C++ (DOS mode) since I believe I will have to deal with a bit of low level stuff which would help me in learning. Other solutions are also welcome. I know Java as well.

Note: 2D games are sufficient for me.

Good question - A decent place to start is

They have some pretty fun courses, no time limit and a decent forum. I actually met some good local dev's there and since have done some stuff together.

I'd also look at getting into the yearly Global Game Jam ( It's a really great experience for novice and professional devs. You can also meet local people.

I mention "local people" cause sometimes its very difficult to do a game on your own - it really helps to have people to collaborate with. Though it brings in problems of its own (schedule conflicts, motivation, etc).

I'd take a look at the following books:






This are just a few books on the top of my head that I've enjoyed in my travels.

I'd focus on a language like python that'll get you up and running quickly. Not C++ - I think you lose a lot of productivity on the language it self, templates, smart pointers, vtables, etc. And then you have all the different version of DX, Win32 GDI etc. I think you'll be more productive in a different language. Maybe lua + python?

Also, I'd seriously look into mastering an engine. I wrote my own, and it was a great journey, but we never completed the GAME! We spent 6 months writing the engine, 2 months writing the game and got burnt out. Next time I'd use an engine for sure!

  1. Unity3D works on iphone, web, desktop.

  2. Torque is another leader, though I didn't find this one as slick as Unity.

  3. Cocos2d is a iphone specific framework, based on a python framework. Really slick.

Another option is taking an existing game that allows Mods (HL2, Quake, etc) and build some mods for it. You can probably find tons of forums and groups already doing it and perhaps contribute to an existing project or start your own.

Another really gnalry idea would to be to get the Blue Book


And don't stop till you understand and have worked through it!!! You'd be a pretty good openGL / C coder by the time you made it through that book (cover to cover). Set aside a few months...heh.

Don't forget - you can always start with paper-prototyping games, you don't have to start building computer games.

Good luck!

I would like to understand/conceive a 3D game engine. Which books/references/tutorials would you recommend? I would like them to be about C++/DirectX and not Java.

Take a look at: Game Engine Architecture ISBN-13: 978-1568814131

First, let me tell you, I am not really interested in making my own rpg engine (at least not in the near future, hehe), but I do feel like I want to understand the internals of how a rpg engine works. Why? Well, because I like to read about programming and design, It keeps me motivated and excited, and because I know I will learn a lot, for, even when I have been programming for some years now, I never stop considering myself an ignorant... there are simply SO many things involving a game engine (specially rpg ones, like branching storylines, and items and economics!) I'm eager to know.

I've been searching (and thus, finding) lots of info online, but it is never focused in what I'm interested (most of it talks about the mathematics and AI algorithms implementation, which I know quite well), which is the design of overall structure, patterns, scripting engine, decision engine... damn, so many things I can't even imagine, since I've never done any game programming.

I hope you know have an idea of how I feel, and how I want to learn for the sake of learning, and why would I want you to tell me if you know if there exist books touching the topics that interest me the most.

I can relate. This same motivation is what caused me to write MUD++ back in the early 90s. In it, I taught myself UNIX system / socket programming, threading, event handling, complex data structures, disk and in-memory database management, bytecode and interpreter implementation, parsing, etc.

I wasn't aware of any books, but I just took a look and found:

Not that I recommend it, but you might give it a try.

Try to make use of available tools and technology, try not to spend all of your time working on reinventing the wheel. That was my mistake and I didn't develop the game side enough before finally tiring after a couple of years, but if not for the experience I would not have learned what I learned that helped me through my career. I later was able to work on a game for Disney, and used those skills.

If I did it over again, I'd do the performance sensitive engine in C++ again, but I'd do all the rest of the game logic in an embedded language (Python, Ruby or Perl are all embeddable). Lesser known, but good are Lua, Tcl, and even Javascript.

Also, something to look into, the sort of persistent puzzles / quests inside the game lend themselves to what we call a "continuation." Ruby supports them, plus some Virtual Machines do as well (Parrot has full blown continuations, Mono also has a 2nd class flavor). If you can wrap your head around it, it is a powerful tool for adventure game implementation where you have to retain the state of a puzzle or quest over a long period of time, even persistent between playing sessions.

The best book I've read on the subject of game engines is 'Game Engine Architecture' by Jason Gregory. It gives a bigger picture view and covers a broad range of game engine systems. And the book doesn't give much implementation details (only where necessary to explain a specific concept).

Covering such a broad range makes it impossible to go into depth on any one subject, so the gameplay part (which it seems like you're mainly interested in) is only covered in one chapter, but still; if you want a good overview of the systems in a game engine and their interactions then this book is on the top of my list of recommended books to read.

The book requires a certain amount of previous coding experience, but not game specific experience. So I wouldn't recommend it to someone who just read a 'Learn C++ in 21 days'-book and wants to create a game engine, but from your question i get the feeling you won't have any problem with it.. ;)

I have good knowledge of C++ and after reading The Elements of Computing Systems I have a basic knowledge of how computers work. I made a list of topics I want to learn next and books I want to buy on those topics. One of them is operating systems, but the one on the top of the list is Game development.

I am still a noob on those topics, so I wonder if I should know how an operating system (unix specifically) works before trying to learn game programming (Opengl, etc). On operating systems I have the book Operating Systems by Tanenbaum, and I want to buy The Linux Programming Interface by Michael Kerish.

On game development I was planning on buying Game Engine Architecture and Game Coding Complete to acquire a general concept of game programming and how engines work and then learn Opengl.

I am really lost on what to do first and I hope this is an appropriate question. What should I learn first, what books should I read and in what order. Should I learn how a VGA works before trying Opengl? Are there any other topics I should know before delving into games programming. I am asking this because I like to know what I am coding, what the functions I am calling do under the hood, I don't like holes in my knowledge.


Fluffy opinion answer incoming. Take with grain of salt.

The nice thing about programming is that that you don't need to learn everything about everything to do one thing effectively. Knowing exactly how to implement a video driver isn't required for using OpenGL effectively. The point of OpenGL is to abstract that out so you don't have to worry.

Since you want to do game development, make a project. Like recreating Asteroids using OpenGL for graphics and writing all the game logic yourself. And set about completing it. In the process you'll learn much more than simply reading. Use books as reference. At least thats what I've found works for me.

The Operating Systems book is pretty good. Its the one I read in college. But those concepts presented in it, though interesting, are not something you'll have trouble learning simultaneously with game development or anything else.

Also you should read this: It's a great article series that teaches linux driver development and operating systems concepts in the process.

I've recently started a project, building a physics engine. I was hoping you could give me some advice related to some documentation and/or best technologies for this.

First of all, I've seen that Game-Physics-Engine-Development is highly recommended for the task at hand, and I was wondering if you could give me a second opinion.Should I get it? Also, while browsing Amazon, I've stumbled onto Game Engine Architecture and since I want to build my physics engine for games, I thought this might be a good read aswell.

Second, I know that simulating physics is highly computation intensive so I would like to use either CUDA or OpenCL.Right now I'm leaning towards OpenCL, because it would work on both NVIDIA and ATI chipsets.What do you guys suggest?

PS: I will be implementing this in C++ on Linux.


Here is an answer regarding the choice of CUDA or OpenCL. I do not have a recommendation for a book.

If you want to run your program on both NVIDIA and ATI chipsets, then OpenCL will make the job easier. However, you will want to write a different version of each kernel to get good performance on each chipset. For example, on ATI cards you'll want to manually vectorize code using float4/int4 data types (or accept a nearly 4x performance penalty), while NVIDIA works better with scalar data types.

If you're only targeting NVIDIA, then CUDA is somewhat more convenient to program in.

I would suggest first of all planning a simple game as a test case for your engine. Having a basic game will drive feature and API development. Writing an engine without having clear goal makes the project riskier. While I agree nVidia and ATi should be treated as separate targets for performance reasons, I'd recommend you start with neither.

I personally wrote physics engine for Uncharted:Drake's Fortune - a PS3 game - and I did a pass in C++, and when it worked, made a pass to optimize it for VMX and then put it on SPU. Mind you, I did just a fraction what I wanted to do initially because of time constraints. After that I made an iteration to split data stages out and formulate a pipeline of data transformations. It's important because whether CPU, GPU or SPU, modern processors running nontrivial code spend most of the time waiting for caches. You have to pay special attention to data structures and pipeline them such that you have a small working set of data at any stage. E.g. first I do broadphase, so I don't need shapes but I need world-space bounding boxes. So I split bounding boxes into separate array and compute them all together in another pass, that writes them out in an optimal way. As input to bbox computation, I need shape transformations and some bounds from them, but not necessarily the whole shapes. After broadphase, I compute/update sim islands, at the same time performing narrow phase, for which I do actually need the shapes. And so on - I described this with pictures in an article to Game Physics Pearls I wrote.

I guess what I'm trying to say are the following points:

  1. Make sure you have a clear goal that drives your development - a very basic game with flushed out design would be best in game physics engine case.
  2. Don't try to optimize before you have a working product. Write it in the simplest and fastest way possible first and fix all the bugs in math. Design it so that you can port it to CUDA later, but don't start writing CUDA kernels before you have boxes rolling on the screen.
  3. After you write the first pass in C++, optimize it for CPU : streamline it such that it doesn't thrash the cache, and compartmentalize the code so that there's no spaghetti of calls and all the code from each stage is localized. This will help a) port to CUDA b) port to OpenCL c) port to a console d) make it run reasonably fast e) make it possible to debug.
  4. While developing, resist temptation to go do something you just thought about unless that feature is not necessary for your clear goal (see #1) - that's why you need a goal, to steer you towards it and make it possible to finish the actual project. Distractions usually kill projects without clear goals.
  5. Remember that in one way or another, software development is iterative. It's ok to do a rough-in and then refine it. Leather, rinse, repeat - it's a mantra of a programmer :)

It's easy to give advice. If you wanna do something, just go and do it, and we'll sit back and critique :)

I am encountering following issue in my .Net application:

It is a game server so there are around 150 threads to process all time-related logic, and some of them are Threading.Timer instances. The server was running fine at the beginning and to some point all timers stops working. I tried to start new timers via script executor. The new timers could be started but they are not firing events neither.

Anyone has idea about what could cause all the timers stop working in the process? I am not aware how could this happen theoretically.

System.Threading.Timer "executes a single callback method on a thread pool thread at regular intervals". Considering you are using 150 threads, its possible you are exhausing the thread pool.

Additionally, if you handler takes too long to process an event, Timer might fall behind and queue updates.

Re-think your design

Unless its a major component like scene loading; or audio playback; game makers generally avoid threading in games for reasons of reliability and simplicity.

Instead you may want to consider using:

  • deferred processing - delay processing until some time later
  • batch processing - rather than processing 10,000 items, process a batch of 100 items every 10ms

enter image description here

Gregory, J, "Game Engine Architecture"

I've recently found out that there is a library called "Assimp" for importing models that can be rendering animations in c++ opengl, and now I try to figure out what I have to do, in order to load a textured model and draw it...

1) What format is recommended to export animations from Blender?

2) I have a basic mesh class already, drawing a model. What would I need to modify to support animation?

My data struct:

struct ObjectData {
    vector <glm::vec3> vertices, normals, colors;
    vector <glm::vec2> texCoords;
    vector <GLuint> vIndices, uIndices, nIndices;
    vector <Material*> materials;
    glm::vec3 size, center;

My mesh VBO and draw:

void Mesh::draw() {
    if (initialized) {

        if (texture != NULL) {

        //Tell OpenGL which array to use

        glDrawElements(renderMode, object->vIndices.size(), GL_UNSIGNED_INT, 0);


        if (texture != NULL) {

void Mesh::updateVBO() {
    if (!initialized) {
        glGenVertexArrays(1, &arrayObject);

    //Tell OpenGL which vertex array to use from now

    if (!initialized) {
        glGenBuffers(VBO_COUNT, buffers);
        initialized = true;

    //Set buffer data
    glBindBuffer(GL_ARRAY_BUFFER, buffers[VBO_VERTEX]);
    glBufferData(GL_ARRAY_BUFFER, sizeof(glm::vec3) * object->vertices.size(), &object->vertices.front(), GL_STATIC_DRAW);

    //Set shader attribute data
    glVertexAttribPointer(VBO_VERTEX, 3, GL_FLOAT, GL_FALSE, NULL, NULL);

    if (object->colors.size()) {
        //Set buffer data
        glBindBuffer(GL_ARRAY_BUFFER, buffers[VBO_COLOR]);
        glBufferData(GL_ARRAY_BUFFER, sizeof(glm::vec3) * object->colors.size(), &object->colors.front(), GL_STATIC_DRAW);

        //Set shader attribute data
        glVertexAttribPointer(VBO_COLOR, 3, GL_FLOAT, GL_FALSE, NULL, NULL);

    if (object->texCoords.size()) {
        //Set buffer data
        glBindBuffer(GL_ARRAY_BUFFER, buffers[VBO_TEXCORD]);
        glBufferData(GL_ARRAY_BUFFER, sizeof(glm::vec2) * object->texCoords.size(), &object->texCoords.front(), GL_STATIC_DRAW);

        //Set shader attribute data
        glVertexAttribPointer(VBO_TEXCORD, 2, GL_FLOAT, GL_FALSE, NULL, NULL);

    if (object->normals.size()) {
        //Set buffer data
        glBindBuffer(GL_ARRAY_BUFFER, buffers[VBO_NORMAL]);
        glBufferData(GL_ARRAY_BUFFER, sizeof(glm::vec3) * object->normals.size(), &object->normals.front(), GL_STATIC_DRAW);

        //Set shader attribute data
        glVertexAttribPointer(VBO_NORMAL, 3, GL_FLOAT, GL_FALSE, NULL, NULL);

    //Set buffer data
    glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buffers[VBO_INDEX]);
    glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(GLuint) * object->vIndices.size(), &object->vIndices.front(), GL_STATIC_DRAW);

    //Unbind vertex array

The 'open asset import library' has a model viewer where you can preview the models with all aclaimed supported formats (including animations). I would suggest exporting your animations, to a variety of formats and see if any of them give you wrong results (i.e. render artifacts) and conclude your own awnser. Personally, I had the most success with Collada (.dae) although I used 3ds Max.

To support the animation itself (presumable skeletal): interpolate the animation data (aiNodeAnim) between the key-frames; you need to calculate the bone matrices from the interpolated animation data (create a matrix out of position/rotation etc); calculate the 'animated' vertices by transforming the 'vertices' (aiMesh/aiBone) with the bone matrices that influence them; weight all of the 'animated vertices' and sum them together; render the newly vertices. And this a basic high level overview of animations.

There are tutorials and books that can go deeper into the subject. For example ogldev's tutorial 38, Jason Gregory's Game Engine Architechture has dedicated animation chapter. You can take a look at the source code of assimps model viewer.

LATER EDIT: Please mention not only game programming books, but also more scientific/simulation oriented books written for C++ programmers. As mentioned in one comment, this is why I chose to post the question on a more general SO site. Thank you all!

please, no specialized books presenting algorithms and techniques with C++ snippets - aka any Gems series, etc. Please expand on Scott Meyer's Effective C++ with similar, more complete or better book examples, or take into account that I mentioned a book for scientists and engineers.

Although similar questions have been asked, what I strictly need to know as a collection of opinions is which books are relevant for a person that has intermediate C++ skills, but wants to learn tips, tricks, good practices and polish up on their coding style to develop an edge in writing efficient number crunching applications (these applications should be dedicated to perform mathematical computations with customized structures, rendering/graphics and communicate with the user).

What I would like to see in an answer is a mention of a truly relevant fundamental C++ book, then 2 to 3 books (series also accepted - e.g. Scott Meyers' Effective C++) focused on intermediate to advanced programming tips, one of these 2-3 dealing exactly with tips and tricks for efficient computations within numerical scenarios/simulation/graphics/etc. I think there was a book called C++ for Scientists and Engineers, I'm not sure though how well this is rated as I haven't finished reading it :(. Perhaps a book that illustrates what design patterns are relevant for scientists/engineers/game programmers?

Thank you all. (hope this will help programmers that aren't keen on learning how to manipulate data just for the sake of making a living out of programming, as most average programmers tend to do nowadays).

I found C++ For Game Programmers (2nd Ed) to be a good intermediate-level C++ primer focused on performance-oriented C++.

Video Game Optimization provides good coverage on C++ optimization (at high and low level), profiling tools, and general approaches to optimization (both CPU and GPU).

Before you venture into a specialization, be sure you have a solid grasp of C++. With that being said, here are some books I would personally recommend.

Game Engine Architecture has become the book you want to read for game development. Having read the book from front to cover, I can say the author does a wonderful job of presenting a large amount of material.

Game Engine Gems 1 and Game Engine Gems 2 present excellent topics that for game development also.

If you are new to graphics programming, and you are on Windows, you may appreciate Introduction to 3D Game Programming with DirectX 11. I have read the previous two books in the "series" by Frank Luna and while I am still working on finishing this one, in my opinion they present the most correct material.

I'm new to game developing , I already built a game with SDL/C,Canvas/Js .. all 2D Now I want to learn 3D games everybody tell me to use an engine , My problems are:

  • What's an engine, is it like Unity,UDK.. or like OpenGL,DirectX.. because I found both answers which is which ?
  • How can I make something like OpenGL/SDL I used C but I never knew how to manipulate screen's pixel and low-level stuff? (I just need an idea how to communicate with graphic card and how it works not asking for assembly code or similar)
  • Can you recommend any book that explains how to work with OpenGL/C++,importing objects, animations etc..

A game engine is a development framework for developing games. Unity and UDK are game engines. OpenGL and DirectX are rendering engine. A game engine may have its own rendering engine.

Game Engine Architecture by Jason Gregory is a nice book