Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualInuyashakagome16

Posted 13 January 2013 - 08:36 AM

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. tongue.png (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.


#1Inuyashakagome16

Posted 13 January 2013 - 08:04 AM

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. :P (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. 


PARTNERS