Sign in to follow this  
Waffler

Help understanding Object Oriented Game Design Article?

Recommended Posts

I read the article at: [url]http://www.devmaster.net/articles/oo-game-design/[/url], but I'm having a hard time wrapping my brain around some of the ideas presented. I'm not sure how some of the concepts presented would be implimented in C++. In figure 6-A it gave the following psudo-code for a main loop:
while(appActive)
{
  foreach Entity E in LogicalSpace
  {
    E.DoActions();
    E.Form.Mesh.RenderSelf();
  }
}
The problem is not all Entities have Form. Only the Renderable objects would have Form. In another part of the article it mentioned querying Entities to see if they have certain Actions, States, etc., I'm not sure how this would effectively be done. Would this be done with something like boost::ptr_map mapping search queries to pointers to the Actions and States being queried for? How might the Actions and States be implimented, so that other entities can make use of them? Can somebody maybe give a small source-code example explaining how Entities, Actions, Forms, States, and Spaces could all work together in a game? It seems complex, and I'm not sure how they would all interact with eachother.

Share this post


Link to post
Share on other sites
"foreach Entity E in LogicalSpace"
That means you don't have to step through all the Entities, put the renderable ones into one space and use that.

"how this would effectively be done"
Something like Entity::HasState( const State& ); could be used. There are a lot of ways to make the check fast. Desctiptive States (with static data) can only exist once and Entities could hold references to it. It is easy to compare those.

The rest is explained in the article imo. It is not a trivial topic thou.

Share this post


Link to post
Share on other sites
You can take ations list from Enity to the external list.
e.g. you have a EntityManager which keep 2 lists of actions
active - actions for execute in this game loop
possible - actions waiting for use
In such situation entity register its actions as possible and if it's needed move its to the active list, and in the game loop you do: foreach active.

Such system is similar to listeners systems.

PS. RenderSelf also can be action ;)

Share this post


Link to post
Share on other sites
Actually, this Renderable suff might be the only weak spot in the article. Objects rendering themselves is not a good idea usually. Have some render data at another place and use actions to modify it. Then let a separate renderer draw all the vaild objects for the current frame.

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