Game engine or no game engine

"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.

A game engine is nothing but a library with or without user interface. So if you have a game in your mind that you would like to make, then structuring the common code from the game specific code gives you your own game specific game engine. You can then use those common code and make another game and obviously some new (no matter how small) common code will get included in your engine and it will eventually be extended.

But as you mentioned, if it is just about DX11, then you should be better off by not going to the above mentioned path, because a engine is about everything residing in a game, not only the graphics part.

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....

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. =)

Thank you for the info!

From the sounds of it its like, when you have to make 10 squares on the screen and you feel like you may make more in the future, make a seperate (library) section of code for that and just reuse it really. Possibly add extra options to it so you can get different outputs.

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.

I started looking at he Doom3 BFG source a bit ago and it's a rather large code base. (Obviously) I'll sift through this here soon to understand more.

The Sierra interpreter really seems like an interesting concept. Not something I would want now, but a very nice idea and starting point if you will.

A game engine is nothing but a library with or without user interface. So if you have a game in your mind that you would like to make, then structuring the common code from the game specific code gives you your own game specific game engine. You can then use those common code and make another game and obviously some new (no matter how small) common code will get included in your engine and it will eventually be extended.

But as you mentioned, if it is just about DX11, then you should be better off by not going to the above mentioned path, because a engine is about everything residing in a game, not only the graphics part.

Can you explain your last statement a bit better? I understand that DX11 is really just graphics (and sound if i'm not mistaken.) and really nothing with a game could be taken from that except maybe Collision(?)

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....

I do enjoy coding. However, SOMEDAY I would enjoy releasing something. Right now I work full-time so I have maybe 15-20 hours a week of coding. Right now I just want to learn what I need to just to make a simple game just to understand the process and really get a feel for how its done. In the future however, If i feel that i'm .. decent at it, I would like to TRY and make a game that's sufficient quality wise for release. I just figured that I would make a game using a normal streamline set of steps. Learn DX > Game Engine / No Game engine > Art > Gameplay > Sound > Game. I just didn't want to go pick up like, Ogre and just start making a game where as I could just do it with C++ And DX11 and say I'm done. If it's easier and something that I'll need to know in the future, I'll put together little libraries with basic functions for a game in the sense of an engine.

EDIT:

Well now I feel terrible. :P

http://scientificninja.com/blog/write-games-not-engines < I had this bookmarked and completely forgot about it.

I feel like one of the posts on this thread so far has probably said a few things from this article, but I just didn't pick up on it.

I suppose I was looking for a direction to go in when really all I needed to do was just make the game and run with it. When I get lost / confused with what I'm currently working on sometimes I reach out for someone to tell me what to do, when really the answer is usually biting my toes. I'm going to just work on making a game and just see what comes out of it library wise. (if anything) I would however like to hear the rest of the conversation here about engines for educational purposes though.

Your first few games shouldn't involve any 'engine' consideration whatsoever, whether third party or your own devising. Your first few games should be rather simple games (by today's standards). Pong, Breakout, Tetris, etc.

Anything more complicated than that as your first, second, or third attempt at developing a game presents a fairly high risk of failing to complete. You're throwing yourself into the deep end without a life jacket when you've only just barely learned how to swim. You're bogging yourself down in various details of game engines without the knowledge and experience that makes those details easier to understand. Resource management, scripting, external level editors, and the framework to support it all are all things best tackled after having several simpler games under your belt.

You end up with a much clearer view of what code is common across multiple games, and thus what code makes up a game engine, and consequently are also in a better position to answer your own question yourself, especially since one aspect of that question is personal preference.

That's how I'm going about it now actually. I'm just now starting to create classes for like mouse / keyboard input and a few other things so that it's able to be exported if need be. Which to me, is as close to an "engine" as I want to get right now. After reading all of that and everyone else, I'll just remake tetris a few times and maybe some pong and work my way up. i would rather not get stuck and pissed because it didn't work out / I don't understand the engine and just stop. That's not something I want. :P

As has been stated before, so I'm probably just typing to hear myself think, your engine is just code that doesn't know about anything game-specific. A graphics component will render any batch of triangles it is handed, an input handler just translates hardware signals into query-able information, a model parser will convert any arbitrary mesh file into usable in-memory vertex data. These are all common "engine" pieces. Just because you're writing your own version doesn't mean you're writing an engine, though. Well, not explicitly. Most of the time, when people say "don't write engines", it's because writing a GAME will give you focus and direction, and writing code that solves the particular problems your game needs solved will inevitably create "engine" level code. Unless you just build on top of an existing engine.

Personal anecdote (so standard YMMV disclaimer out of the way):

My current project is big, a 3D fps/rts. I'm being ambitious/crazy. But it's also a giant sandbox for me to learn with. So I'm writing all the parts of the "engine" that I want to roll for myself and feel out - any one of which have pre-existing professional quality options. It's just as challenging in many regards to piece together pre-existing libraries that will do the lower level work for you. As an example, some of the things I'm self-rolling include:

Graphics

AI/Navigation

Resource/Asset handling

Input Management

Asset creation tools (i.e. writing my own game-specific toolchain like a level editor and resource packager)

Things I'm (definitely) pulling in from other sources:

Networking

Physics

Scripting

But I still have to make my game data and framework structure play nice and plug in to the 3rd party libraries.

The point of this lengthy anecdote is that I'm not specifically sitting down to write a re-usable, non-contextual engine. I'm writing my various framework components to be as separable from the specific game data as possible, just as a design philosophy, and that will make my code more reusable in general, but when I created my model and mesh classes, it was to solve a specific problem: I wanted to throw some props into my terrain. I didn't just approach it as "any engine needs a 3DModel object." So I only implemented those functions and properties that would fit my game environment.

(And another plug for not writing anything you don't have to: I used a model-importing library to convert my meshes from .dae files (exported from Blender) to game-specific mesh data. Write a collada parser? No thank you, not interested at the moment.)

As has been stated before, so I'm probably just typing to hear myself think, your engine is just code that doesn't know about anything game-specific. A graphics component will render any batch of triangles it is handed, an input handler just translates hardware signals into query-able information, a model parser will convert any arbitrary mesh file into usable in-memory vertex data. These are all common "engine" pieces. Just because you're writing your own version doesn't mean you're writing an engine, though. Well, not explicitly. Most of the time, when people say "don't write engines", it's because writing a GAME will give you focus and direction, and writing code that solves the particular problems your game needs solved will inevitably create "engine" level code. Unless you just build on top of an existing engine.

Personal anecdote (so standard YMMV disclaimer out of the way):

My current project is big, a 3D fps/rts. I'm being ambitious/crazy. But it's also a giant sandbox for me to learn with. So I'm writing all the parts of the "engine" that I want to roll for myself and feel out - any one of which have pre-existing professional quality options. It's just as challenging in many regards to piece together pre-existing libraries that will do the lower level work for you. As an example, some of the things I'm self-rolling include:

Graphics

AI/Navigation

Resource/Asset handling

Input Management

Asset creation tools (i.e. writing my own game-specific toolchain like a level editor and resource packager)

Things I'm (definitely) pulling in from other sources:

Networking

Physics

Scripting

But I still have to make my game data and framework structure play nice and plug in to the 3rd party libraries.

The point of this lengthy anecdote is that I'm not specifically sitting down to write a re-usable, non-contextual engine. I'm writing my various framework components to be as separable from the specific game data as possible, just as a design philosophy, and that will make my code more reusable in general, but when I created my model and mesh classes, it was to solve a specific problem: I wanted to throw some props into my terrain. I didn't just approach it as "any engine needs a 3DModel object." So I only implemented those functions and properties that would fit my game environment.

(And another plug for not writing anything you don't have to: I used a model-importing library to convert my meshes from .dae files (exported from Blender) to game-specific mesh data. Write a collada parser? No thank you, not interested at the moment.)

Well damn.

Your definition of an engine and what you're putting into your engine and game itself is rather amazing I think. I know that not everything in the engine has to be used for what you're doing. Just like you said at the end about the model-importing library, there are some parts you would just rather not deal with. Just some sections need to be written by you and others can be imported from 3rd parties. It seems like what you are doing is (to me) a bit over my head at the moment but at some point I would like to be there. (As far as what you are creating "engine" wise) I can only imagine how creating "creation tools" as you said, can be. It's something that I know I'll want to do and really want to learn about but baby steps pretty much.

Not everything is made to be reusable in your engine as it will be in mine. I would like to be able to reuse a lot, but just like every other game, somethings will be different and you'll have to modify it for your needs at the time. Like how creating an FPS would be different than a isometric view type of game, it's different in the sense of view and models so some things are different but some can be reused.

So far what I've gotten so far is "Write what you need when you need it." As in if I need to display text on the screen and I'm going to need to do that more and more, than create something to make it easier and possibly more open for me to use with other projects. (or others, depending)