Help with game engine design

Started by
12 comments, last by FritoBandito 13 years, 6 months ago
Quote:Original post by karpatzio
Quote:Original post by Captain P
Quote:Original post by shuwo
Now I've got a new problem. Where do I put all my objects? For example, if I have a lot of game objects (sprites) like Enemy, Player, Fish, etc, where do I "create" them?

I usually make a Game class of some sort and put them there. It may be useful for certain game objects to have a reference back to the Game object - this would allow your characters to create Bullet objects and add them to the Game, or to ask the Game which other characters are nearby.

No need to use globals here, though. If some code needs to know about the Game object, just pass it a reference or pointer to the Game object.


This would create unnecessary dependencies, game logic should be handled by other classes. For example create a sprite collection class that would handle collisions, movement and creation/destruction instead!

Sooo, do you have any other suggestions?
Advertisement
Here's a construct that might help organize your thought (and thus your code) and help sort out some of your details about object ownership and collection:
class Sprite{public:    void rescale(float newScale);    /*etc*/    friend class SpriteFactory;protected:    Sprite();    Sprite(Sprite const&);    Sprite& operator=(const Sprite&);}


Here, SpriteFactory is a singleton factory class who has the sole capability of creating a Sprite. Creation rules - check. The SpriteFactory can take default ownership of any Sprite that it creates and can hand off ownership to something more appropriate later on. This goes a long way in managing object lifetimes. Using this, you can also prune your heap of unused Sprites just by iterating to gather all of your unclaimed children and destroying them. Recycling unclaimed children to satisfy requests for new Sprites is also a possibility. Another approach is allowing the Sprites to simply remain property of SpriteFactory and instead expose methods to tag and retrieve Sprites(get/set interface to hash implementation).

Others will likely have different approaches (or variations on this one), but I feel this would be a step in the right direction.
Quote:Original post by FritoBandito
Here's a construct that might help organize your thought


Why does Sprite need such intricate lifetime management?

A Sprite should really just be a simple type such as:
struct Sprite {    char path[64]; //or an integer handle or opaque pointer or maybe interface or abstract class    float x, y, w, h; //could store as s,t texcoords    //flags for mipmaps, compression, etc}


Which then interacts with a renderer like
namespace R2D {    void Draw(Sprite &, Color, float x, float y, float w, float h);}


It should be the application's job to store the position of the sprite, not the renderer. Then there's no need for complex object management, "friend" classes, or patterns. The renderer is responsible for the underlying textures and their lifetimes/etc.

Remember to avoid the OO tendency to think in terms of interacting with a single object. This is rarely the case in games. It's better to write a service that interacts with many either relatively simple or opaque types.
Anthony Umfer
The sprite was actually just an example that could be expanded upon and applied where appropriate. The goal of the post was to present something that starts the mind down the avenue of considering who should own what and why. The answers to those questions are what is important, not the example at face value.

This topic is closed to new replies.

Advertisement