^ that is the question.

I've been learning DX11 now for quite some time and I've had a question that I haven't been able to find a decent answer for yet.

"After I learn DirectX should I just take what I've learned and make a game? Or do I need a game engine?"

I think that's a decent question. I feel like i COULD make a game with what I've learned, but should I be using an engine instead of just base DX11.

So

"After I learn DirectX should I just take what I've learned and make a game? Or do I need a game engine?"

and probably, "What engine should I be looking at?"

I feel like this question has been asked rather often, but this is more directed towards DX11.

"Games first, and games then, but never engines"

That's my thought

You could make a game with what you've learned, but i think the question is "Is your intention to make a game (a product), or t create a game as in a stepping stone to learn the ins and outs of an engine development".

If you just want to make a game, maybe you're better off using an existing engine, as it saves you a LOT of trouble along the road. On the other hand, by making your own engine, you learn the underlying aspects of a game engine (not just the game part itself).

The first choice is easier and faster, the second is more (a lot more)slower, but more educative.

About the choice of an engine, i can't help you (i know of some, but they use OpenGL, and not D3D), but someone else can probably help you.

Also, yes, this question gets asked rather a lot, although probably not directed to DirectX, but to game engines in general.

Hope i helped.

You could make a game with what you've learned, but i think the question is "Is your intention to make a game (a product), or t create a game as in a stepping stone to learn the ins and outs of an engine development".

If you just want to make a game, maybe you're better off using an existing engine, as it saves you a LOT of trouble along the road. On the other hand, by making your own engine, you learn the underlying aspects of a game engine (not just the game part itself).

The first choice is easier and faster, the second is more (a lot more)slower, but more educative.

About the choice of an engine, i can't help you (i know of some, but they use OpenGL, and not D3D), but someone else can probably help you.

Also, yes, this question gets asked rather a lot, although probably not directed to DirectX, but to game engines in general.

Hope i helped.

You do have a point. I would LIKE to understand the in's and out's of an engine personally. And learn what I would need to actually build one. A game engine is just really, an easier way / better access to functions with the graphics library correct? Like easier ways to access keyboard commands and displaying text on screen and etc.

That aside, I would enjoy knowing how to make my own, however I don't want to be so immersed in it that I lose interest because all I'm doing is making an engine.

You do have a point. I would LIKE to understand the in's and out's of an engine personally. And learn what I would need to actually build one. A game engine is just really, an easier way / better access to functions with the graphics library correct? Like easier ways to access keyboard commands and displaying text on screen and etc.

That aside, I would enjoy knowing how to make my own, however I don't want to be so immersed in it that I lose interest because all I'm doing is making an engine.

A game engine is not just about graphics. The engine basically refers to everything in the game that's not necessarily game-specific. If you wrote two games, everything that could be done with the exact same code, that would be the engine.

So... data pipeline, rendering, UI, physics, sound, scene management, scripting...

You can either use an off-the-shelf engine like Unity, or you can build the game from scratch yourself (maybe with additional 3rd party libraries). In the case you're building stuff yourself, then building the engine is recommended. By this I mainly mean to think ahead of time of what your code needs to do for the game, think about whether this is stuff you could use in other games, and then think of how to abstract it out into a separate library so that it can more easily be reused later. And, congratulations, you now have a game engine.

Also, the best way to understand how game engines work is to build one.

You do have a point. I would LIKE to understand the in's and out's of an engine personally. And learn what I would need to actually build one. A game engine is just really, an easier way / better access to functions with the graphics library correct? Like easier ways to access keyboard commands and displaying text on screen and etc.

That aside, I would enjoy knowing how to make my own, however I don't want to be so immersed in it that I lose interest because all I'm doing is making an engine.

A game engine is not just about graphics. The engine basically refers to everything in the game that's not necessarily game-specific. If you wrote two games, everything that could be done with the exact same code, that would be the engine.

So... data pipeline, rendering, UI, physics, sound, scene management, scripting...

You can either use an off-the-shelf engine like Unity, or you can build the game from scratch yourself (maybe with additional 3rd party libraries). In the case you're building stuff yourself, then building the engine is recommended. By this I mainly mean to think ahead of time of what your code needs to do for the game, think about whether this is stuff you could use in other games, and then think of how to abstract it out into a separate library so that it can more easily be reused later. And, congratulations, you now have a game engine.

Also, the best way to understand how game engines work is to build one.

Okay that makes sense to me. So, (Exp) I'm going to display a sprite on the screen in a certain fashion, so I would make that into a separate section (library / engine) where it could be reused over and over. (in a very generic way) if i understand what you mean correctly. I do agree that it seems like making an engine would be the best way to fully understand how it works. I suppose I'll start looking into that. Any suggestions / articles / books to read about the subject?

Okay that makes sense to me. So, (Exp) I'm going to display a sprite on the screen in a certain fashion, so I would make that into a separate section (library / engine) where it could be reused over and over. (in a very generic way) if i understand what you mean correctly. I do agree that it seems like making an engine would be the best way to fully understand how it works. I suppose I'll start looking into that. Any suggestions / articles / books to read about the subject?

Yes. The main thing is to have the separate lib folder where your engine code will go, and that it has no dependencies on the game code. Once you have this, now you have an engine that you can include and use in multiple games.

But, ok, for the specific example. You should begin by defining the thing you want to do, and then for each "assumption" in the task ask yourself if you can abstract it at any higher level. So you might begin with "i want to draw an alpha-blended screen-aligned textured quad". Now of course, you can simply make a new function in your engine somewhere that takes a texture pointer, UV coordinates, some XY screen coordinates, width and height, and it draws the quad. Done!

However I'd then ask myself things like... "Do I always want to render this alpha-blended, or sometimes using other blend modes?" "Do I always just want to render a quad, or do I really want to be able to render a generic mesh?" "Do I maybe want to render a generic mesh with different materials, maybe with different scalings, etc?"

I'm not saying that you should over-complicate things for yourself, only that thinking things out ahead of time will make life easier for you later. If your game is only 2D, or you're only doing the HUD, then drawing screen-aligned quads is a perfectly ok thing to do. Also, defining your functionality at higher levels will make it easier later if you want to make your code platform-independent. Still, that's a separate issue.

As far as starting out, I'd start with subfolders for math, graphics, and audio, since those are the basic functionalities that you'll almost always need. Then as you get more experienced everything else will start to fall into place.

I dont have recommendations for books/articles, but maybe others do. I think the best way to learn this is to focus on a small-scale game and then do it. Yes, writing your own engine is more time consuming, but you'll learn more. Also, if your project is modest (like for example a 2D version of Asteroids, or something like that)... then the amount of stuff you're writing for the engine is really not that much. In fact, your entire graphics lib code might be like:

void InitGraphicsEngine();

void BeginFrame();

void RenderTexturedQuad(...);

void EndFrame();

I mean, that's an extremely simple case but in theory you could start off with very little engine code and build a whole game on that. Then as you progress you'll want more functionality... like you might want to be able to rotate those sprites... and as you do this you'll learn more about all kinds of things without it being handed to you by someone else's engine. More work, yes, but more learning too. =)

You can take a look at the Doom3 BFG source code to see what an engine looks like. It's very clean code. The book Game Engine Architecture (Gregory) is also a good introduction to the subject. I would also recommend taking a look at some early engines, like Sierra's Adventure Game Interpreter. (Don't forget to check out the spec!)

"Engine" can be a blurry term, but take a look at what Sierra did. They defined a sort of "machine abstraction" that took as input resources (logic, pictures, sounds) and produced as output an "interactive graphic adventure". The engine is then kinda like the stuff between the input and output.

I don't think you need to make an engine to have a good understanding of how it works, especially if it has a well defined architecture (because then it looks kinda straight-forward, a machine or service provider with various components that do particular tasks). What you would probably end up with is a deeper understanding of how various platforms work, how compilers work, how your language manages memory, how data is accessed and transported, how to better architect libraries, how to deal with floating point calculations robustly, etc... kinda nuts and bolts stuff.

Depends upon your end goal.

Do you want to just have fun coding, or do you want to release something?

If you start work on an engine, you will rarely finish it....