Sign in to follow this  
beebs1

Architecture Questions

Recommended Posts

Hiya, I'm trying to design the entity system for my game, but unfortunately I'm having some trouble fitting everything together! I was wondering if anyone could help? The problem I'm having is with how an entity system and scene graph are related, and how they should interact. To me, an entity is a 'tangible' object in the game world such as a player, weapon, trigger volume or an obstacle. From this, I think every entity will need a position, and could also have a bounding volume. I guess they should also be composed of seperate parts such as a mesh, simple physics representation, sounds, and possibly scripts. The component architecture seems a good way of dealing with this. I would also like to use a scene graph to position dynamic objects in the world, and to maintain a bounding volume hierarchy so I can also efficiently cull dynamic objects. These two responsibilities seem to work well together. I'm not sure whether these scene graph 'objects' should be actual entities though, or more primitive types like geometry, 3D sounds, etc. These are the ways of linking the systems that I can think of: - entities should contain references to scenegraph nodes, or - entities should be a type of scenegraph node, or - merge them, so all scenegraph nodes are entities, and vice-versa Which do you think is best? I'd be very interested to hear anyone's thoughts, or how you've handled this before. As always, thanks very much for any input [smile]

Share this post


Link to post
Share on other sites
In my very humble opinion, entities should not care about how they are rendered. They should only store the information required to react and behave as expected (which may include collision meshes, for instance).

Then, an entirely different subsystem is responsible for observing the entities and translating them into a scene graph, which is then rendered, as well as the sounds that should be played. For obvious performance reasons, it is more efficient to alter the scene graph from frame to frame rather than rebuild it from scratch.

That way, entities (game logic) and the scene graph (viewing) are kept separate.

Share this post


Link to post
Share on other sites
Quote:
Original post by beebs1
Interesting, thanks. So that would be the model-view-controller design? I'll have to look into that.


I'm nitpicking, and a bit off-subject...

This is not the MVC architectural pattern, although it's close to that. MVC is synchronous (change in the view is triggered by changes in the model). This is a bit tedious to do that in a game, as you don't want to refresh the view every time a tinny bit is modified somewhere. The typical render loop is a pipeline, which is quite a different beast (gather input, then update, then render). Of course, you can still decouple the model, the view and the controlers - but that doesn't transform your architecture into MVC. It's just decoupling.

Speaking of that, there are many architectural models that looks like MVC but aren't MVC. The most beautiful one is probably the PAC model (presentation-abstraction-controler) that looks like some kind of cascaded MVC (quite similar to HMVC for Hierarchical MVC). PAC is used to implement windowed softwares (dialog boxes, ...) and works great if your game is based on this paradigm (better than the traditional MVC I mean).

Don't let yourself be fooled by a list of names. Decoupling the model, the view and the controler doesn't mean that you're implementing the traditional MVC pattern. It just means that you're decoupling everything [smile]

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