Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Ben F

Decoupling the game from the gfx

This topic is 5867 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

Is there a good way to decouple the game logic from the graphics used to render it? For example, if i were making a chess game (or any other type of game), how could I have the logic move a piece without having to worry that the move might need to be animated or the last move might still be animating? Basically I want the logic of the game to not have to worry at all about what I do with the graphics.

Share this post


Link to post
Share on other sites
Advertisement
Generally, that's done by representing the positions of the objects in a way that doesn't depend on graphics at all, THEN writing the routines that read the object's positions and data and render them accordingly.

Looks like you're making the distinction between object behavior and object rendering. Sometimes, there are benefits to doing both at the same time, but I prefer to make all objects behave first, THEN render them all.

[edited by - Waverider on June 27, 2002 1:16:27 PM]

Share this post


Link to post
Share on other sites
It''s not only your wish to split game and presentation, but also mine. So I''ll tell you the way I approached it.

I am creating (for an realtime strategy game)

1. game Core:
Herein only rules and the gamepieces are stored. Not the way the gamepieces are displayed (I use 3D) but only their presence.
Additionally you need up to 3 sets of instructions:
- game core information: Every aspect of the game to be represented has to accessible by methods (Yeah) or public fields(Yak!). You can think of this as the output of the game
- game core commandset: Here comes the input to the game.
Any aspect of the game that is modifiable has to be exposed by methods. This time it will be hard to dodge methods.
For you it would be methods like move gamepiece at (x,y) to (x'',y''). Then it is the duty of the core to check if the move (or any other input) was valid ( sidestepping pawn, not your turn, no piece on (x'',y'')...). The result of the operation on the core has to be collected by the information methods and fields, including error messages.
- game core update: Probably not applicable for you but anyway. The game not only reacts to outside influences. For my RTS game it means updating the physical effects, movement and so forth. In some sense this belongs to the commandset but it''s used so frequently that I consider it it''s own type.

2. Game Representation
This includes (or not) a GUI and whatever you need.
My way is to permanently update the visuals and call whichever information functions of the core I need at the moment.
This is where all graphics are associated with the symbolic information returned by the game core. But the representation is not the only one interested in the game state. AI and Networking senders also use this interface.

3. game Input
Trivial you might say, but there are more uses to a input interface than human input. Again AI and Networking code, but also Scripts use this interface.


If you split the game and the GUI absolutely clean it should be a matter of very little code to replace a console-textbased interface by a tuned DirectX9 engine. Provided you have both the text and DX engines.



---------------------------
I may be getting older, but I refuse to grow up

Share this post


Link to post
Share on other sites
The way I do it is to represent everything about the world in a "world database" which is mostly a conceptual object consisting of lists of objects(particles, npcs, player character, items etc... for an rpg) and the terrain their in. To update the world I step through the object list and tell each object to update. Then to render the game I use the camera position to render the terrain and then step through all the objects and draw them if they are in view. Thats the basic outline; but of course the mouse interface and collision detection among objects and with the terrain adds alot of complexity which I am trying to figure out now!

For inspiration I meditate over the Simp Engine diagram on page 709 of OpenGL game programming.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!