Sign in to follow this  

how should I seperate visualization from implementation logic?

This topic is 3810 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


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

Share this post


Link to post
Share on other sites
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]

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

This topic is 3810 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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