Sign in to follow this  
Followers 0
jopy

[Resource Management] object tracking within game engine

4 posts in this topic

Hello, I am currently writing a game engine and I have come across a problem in developing it. Long story short (I am using C++) I'm using a vector to store pointers to classes that inherit from the game_object class (vector< ::game_object*>). This limits me from adding functions to classes that inherit from game_object without modifying the game_object class first. My question is: What would a better system for indexing (storing pointers of) objects that would also allow me to use derived classes that don't exactly match the base class function for function.

Thanks
0

Share this post


Link to post
Share on other sites
[quote name='jopy' timestamp='1308692025' post='4826152']
This limits me from adding functions to classes that inherit from game_object without modifying game_object first.
[/quote]

Stop using that design if that's what you really want to do. You're abusing the functionality and probably making a noodle mess while you're at it.

[quote]
What would a better system for storing pointers to objects that would also allow me to use derived classes that don't exactly match the base class.
[/quote]

First off.
1: what are your intentions for these objects.
1a: how will these objects be used.
1b: how will these objects be created and destroyed.

2: do you really need to generalize these objects this much?
0

Share this post


Link to post
Share on other sites
[quote name='freeworld' timestamp='1308692398' post='4826154']
[quote name='jopy' timestamp='1308692025' post='4826152']
This limits me from adding functions to classes that inherit from game_object without modifying game_object first.
[/quote]

Stop using that design if that's what you really want to do. You're abusing the functionality and probably making a noodle mess while you're at it.

[quote]
What would a better system for storing pointers to objects that would also allow me to use derived classes that don't exactly match the base class.
[/quote]

First off.
1: what are your intentions for these objects.
1a: how will these objects be used.
1b: how will these objects be created and destroyed.

2: do you really need to generalize these objects this much?
[/quote]

1: they contain the bitmaps and logic used for in game objects eg.in pong you'd have a paddle object and a ball object
1a: they are run once per frame inside of a game, they can be used in many ways eg. a paddle in a game such as pong
1b: though functions within the class called in-game

2: no I simply need a way to index all of them in C
this bring me back to my original question, how can I index a wide variety of classes with similar (but not the same !) functions in ?
0

Share this post


Link to post
Share on other sites
Solution: Don't store one master list of game objects.

Some approaches:
[list]
[*] Store different lists of different objects. Just have a handful of collections for the "top level" concrete types, player, enemy, pickup, whatever. Great for simple games. As the number of "top level" types increases, the number of interactions can make this unmanageable.

[*] The Model-View-Controller (Google: MVC) pattern/architecture. Break the objects into three types:
[list]
[*]Model - the pure game logic (pac man's position and orientation, a tetris piece's position, orientation and type, etc). Unaware of the other two.
[*]View - the "renderable" data. Generally graphics, but can also include sound etc. Aware of the model.
[*]Controller - Something like an input or AI, or network process that drives changes in the underlying model. Sometimes aware of the view for notification purposes.
[/list]
There are lots of resources about the MVC design architecture on Google, its good for all classes of applications.

[*] Store different "aspects" of the same object in different lists. For a more complex game, decomposing the objects into an "entity" (effectively an identifier/lifecycle manager for any game object) which has a bunch of components (e.g. renderable component, physical component, game logic component, weapon component, health component, etc ...). Each component might live in a separate subsystem, so the physics subsystem just sees a bunch of physical objects that need to be moved and tested for collision. The graphics subsystem just sees stuff that should be rendered, and so on.
[/list]
MVC can be applied to either of the others to isolate the various dependencies, or as a higher level way of separating your overall architecture. For example in a networked game it can be great to know there are no graphical dependencies in the game's core.

This isn't exhaustive, it is just to give you ideas to research. The main thing I would want to you consider is to scale your architecture around your game - there is no 100% right answer. It can be easy to over-engineer - if you're posting in For Beginners, do not be ashamed to go with option #1. I've written games using it, and read the source for other games that use it. It is often the simplest, clearest and most mantainable solution.
1

Share this post


Link to post
Share on other sites
[quote name='rip-off' timestamp='1308693302' post='4826157']
Solution: Don't store one master list of game objects.

Some approaches:
[list][*] Store different lists of different objects. Just have a handful of collections for the "top level" concrete types, player, enemy, pickup, whatever. Great for simple games. As the number of "top level" types increases, the number of interactions can make this unmanageable.[*] The Model-View-Controller (Google: MVC) pattern/architecture. Break the objects into three types:[list][*]Model - the pure game logic (pac man's position and orientation, a tetris piece's position, orientation and type, etc). Unaware of the other two.[*]View - the "renderable" data. Generally graphics, but can also include sound etc. Aware of the model.[*]Controller - Something like an input or AI, or network process that drives changes in the underlying model. Sometimes aware of the view for notification purposes.[/list]
There are lots of resources about the MVC design architecture on Google, its good for all classes of applications.

[*] Store different "aspects" of the same object in different lists. For a more complex game, decomposing the objects into an "entity" (effectively an identifier/lifecycle manager for any game object) which has a bunch of components (e.g. renderable component, physical component, game logic component, weapon component, health component, etc ...). Each component might live in a separate subsystem, so the physics subsystem just sees a bunch of physical objects that need to be moved and tested for collision. The graphics subsystem just sees stuff that should be rendered, and so on.[/list]
MVC can be applied to either of the others to isolate the various dependencies, or as a higher level way of separating your overall architecture. For example in a networked game it can be great to know there are no graphical dependencies in the game's core.

This isn't exhaustive, it is just to give you ideas to research. The main thing I would want to you consider is to scale your architecture around your game - there is no 100% right answer. It can be easy to over-engineer - if you're posting in For Beginners, do not be ashamed to go with option #1. I've written games using it, and read the source for other games that use it. It is often the simplest, clearest and most mantainable solution.
[/quote]

Thank you for your advice

I'll definitely look into the MVC architecture since Im trying to make a fairly solid base engine for a game I'm thinking of making with a few colleagues
0

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  
Followers 0