Well I was looking through all of the gamedev.net articles (I even stopped to read a few that looked quite good, I wasn't let down), and I still haven't found an article explaining a bit more on design theory. What I meant by that is the common components of game engines. I've heard the term scene manager before, I have no idea what they do, as well as components of these modules like a sprite animation system or something. I'd be suprised to find an all-in-one guide about this, but maybe you guys might know a few guides that cover important subjects about game engine components. I'd like to know the theory behind them, what they are, how they work, and maybe some psuedo-code piecing things together into some logical sense. I'm currently using SDL to build a fun tile-based RPG engine, but every time I go back to redesign it, I end up getting a little further, but I keep cluttering up the rendering/input loops into a mess in the main() and I'm trying to figure out how to manage my entire project better. Maybe that's the type of article I'm looking for as well? Thanks!

I'm currently reading a book about 3d programming...
And something I really didn't think so much about before (being a freak for speed), I always tried to make everything so overly complicated as possible.

After a few hundred pages it really was clear to me, mainly, what the engine should do for you, is to really do everything for you that is, if you say you want 2 sprites there and there, you don't give a shit about the rest, the engine draws them in the right order, lightning etc etc, nothing (more or less) unnecessary should be done by you if it can be done by the engine.

This really helped be think more clear about how to design the engine as all is so much more clear to think about when you only need to know that the interface should require minimal amount of information, while giving as much flexibility as needed.

And having it handle textures internally, materials, floormaps etc.

So what this means is that, if you are going to design a room, you draw some floors, some walls, and put in a few objects using the interface, then you tell him "draw or die", and it draws everything the way you want, no external loops, no thinking of in what order it should be drawn (outside the engine).

Regarding game engine components, it is pretty much what you can think of, graphics, sound, input, network, scenemanagement etc.

Hope it helps some at least.

(Perhaps not the best explanation, but remember, the engine should be doing the work not the application, just like a theme park, the kids have fun, while the workers have to do all the dirty work)
(I really recommend you buy a book, can feel boring to do (did for me), but it was more fun than I imagined ;))

Well I understand what a game engine does, then you build the application/game on top of the engine, but I'm trying to grasp what components are vital for a game engine (not even particulrarly 2D/3D engines). I can make a simple class to handle reading of my map file types and store them in some base class where all data is stored, or I'm sure there are systems people devise to handle the hierarchy of systems and subsystems to make an entire engine work. I think I'm more looking for a diagram with an explanation more than anything. I'd like to know what a game engine consists of before I actually try to make one and/or efficiently arrange it in a fashion. I think that book is the next step in what I'm looking for. I'm not strong in my 3D math, so I've been sticking with 2D design initially as not to confuse me more. =)

Something I had trouble with is the concept of a scene graph. I read about it time and time again, but I never really understood what it was. During this last school year, I was building a graphics engine and it suddenly just clicked. That wasn't until the last couple of weeks of production, mind you, but luckily, I had designed everything so that it fit together nicely.... A scene graph took me an hour or two to throw in.

The basic concept, as I understand it, is a way to tie together different objects dynamically for purposes of position, rotation, scaling, etc. From what I hear, it's not a good idea for determining what is visible to render, or for physics, but I found it very handy for things like skeletal animation.

The basic concept is that each object can have a list of other objects connected to it.... Those other objects will inherit the parent object's position, rotation, scale, etc. This can filter down through a hierarchy.

For example, we had issues designing animated 3d objects to put into the graphics engine (modelling problems, not code problems). So, we used a scene graph to create a skeletal animation system. We had a torso as the root object, with a head, two arms, and a hips object all connected to the body. Legs were connected to the hips and hands were connected to the arms. When you moved the mouse horizontally, the body would rotate left and right, causing all the attached objects to rotate with the body. But moving the mouse vertically would make the arms pivot up and down, which in turn moved the hands with the arms. This gave us a make-shift animation to use (we had Lego men), but the concept could be easily applied to more complicated schemes.

Another example is that we had two different nodes the camera could attach to. One was the character's head and the other was a sky node. The camera would inherit the node's position and rotation. This way, we could dynamically move the camera back and forth without actually changing the orientation of the camera.... Rotating it at one node wouldn't affect how the camera was oriented at the other node.

EDIT: Wow, six people replied before I finished typing. By the way, I second the mention of David Eberly's book(s). He actually has one or two more in the series; I think the one from 2004 is the most hands-on; less theory and more actual implementation. I think that's the one Saruman mentioned.

Thanks guys! I just have one final question, what is a scene manager? =/

Thanks again!