Sign in to follow this  
chbrules

Game Engine Design/Structuring

Recommended Posts

chbrules    170
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!

Share this post


Link to post
Share on other sites
Saruman    4339
First I would recommend David Eberly's book: Game Engine Architecture.

Secondly I would say to download the source to various engines such as Ogre, Irricht, Axiom, etc and read through and see how the samples work. From there you can drill down and find out exactly how the subsystems are built and how they interact with each other.

I really do recommend that book though as it is the best material on the subject imo.

Share this post


Link to post
Share on other sites
Syranide    375
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 ;))

Share this post


Link to post
Share on other sites
chbrules    170
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. =)

Share this post


Link to post
Share on other sites
FrankCashio    168

I would recommend you pick up Game Coding Complete, Second Edition. I think it has what you’re after. I don’t think your going to find a better resource it’s 900 pages long and just manages to give a fairly good overview of game engine design. This should tell you something about the complex nature of video games.

-Frank

Share this post


Link to post
Share on other sites
hannibal84    220
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.

Share this post


Link to post
Share on other sites
matches81    474
hannibal84: Wow, that´s a completely different approach to the use of a scene graph than I have thought of. I also read some articles about that (but not yet implemented one, coming soon I hope). As I understood it, a scene-graph is commonly used to group the renderable objects according to their needed textures, render states (and eventually transform stages) in order to get at least state changes as possible in order again to get better performance.
This grouping is normally done using a tree-like structure, first sorting factor being the most expensive state changes. But as I have not yet implemented one and I am not too sure if I´m right, that might as well be complete nonsense I´m talking.
Of course your approach seems to do grouping based on transform states.

chbrules: Could it be that the scene manager is something quite similar to the scene graph? I guess a scene manager could be a class that is 'just' putting the objects into the right node of the scene-graph in order to maintain as less state changes as possible. At least that is what comes to my mind first when hearing scene manager. A class that manages all objects in the scene and gets them ready for rendering.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this