I have a question of how I should manage the logical seperation of the game implementation from visualization. Say for instance, I have a "Dirt" object. is there a best practice for seperating the "this is how it should be displayed" from "this is how the game uses it"? Thanks, -Jason

and fyi, how i'm doing it right now, is i'm not coding any visualization information, just stuff that matters to the actual simulation.

I have a seperate visualization sub-system that then reads the various simulation objects that should be rendered, and then acts appropriately (meaning, I programatically pick the model/render info based on the objects state)

I'd like to hear if there's a more elegant, or even "more traditional" solution to this.

Thanks,

-J

Search for the Model-View-Controller pattern.

http://en.wikipedia.org/wiki/Model_view_controller

Ordinary software engineering practices apply to game dev too.

And read the thread 15 lines below yours:
http://www.gamedev.net/community/forums/topic.asp?topic_id=454472

It's about linking physics to graphics -> visualization from simulation or logic, if you want.

--
i really like to know how much redundant information a forum contains approximately, with the same questions popping up every month. i am looking forward to a reply-pattern catalog.

[Edited by - stephanh on July 9, 2007 9:56:50 AM]

thanks for those links, from looking at those links, I think the MVC patern might be the best bet, i'll do some more research and post back how it goes!


and FYI, if there are repeat questions, you should have the moderator put it in the Forums's FAQ (I looked there for an answer and searched the forums before I posted this question)

In many engines there is a concept of a "Renderable" (although it goes by many different names) which is often a base class that an object must inherit in order to be "hooked in" to the rendering system. This base class might be as simple as a single virtual Draw() method. To make a visual representation of an object, the application would create a class which inherits from this base and add whatever data is necessary for visualization of that particular object. Then, the application-level object might have a member variable which is the renderable-derived object (although sometimes it might be preferable for the application-level object to inherit from the renderable directly).

The most typical example of this is a high-level "Actor" object, which has a ModelInstance, which is a Renderable. The ModelInstance would have a pointer to the model data (or the class which encapsulates it).

There are lots of permutations on this theme, though, and no two engines do it exactly the same way. For example, in our current engine we have an Actor which inherits from a ModelEntity which has a ModelInstance. The ModelInstance is not a "Renderable" per se, rather the ModelEntity is.

I'm not sure I've understood your question exactly, but hopefully that helps.