Jump to content

  • Log In with Google      Sign In   
  • Create Account

[Resource Management] object tracking within game engine


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
4 replies to this topic

#1 jopy   Members   -  Reputation: 100

Like
0Likes
Like

Posted 21 June 2011 - 03:33 PM

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
+1 for C / C++ / Python

Sponsor:

#2 freeworld   Members   -  Reputation: 329

Like
0Likes
Like

Posted 21 June 2011 - 03:39 PM

This limits me from adding functions to classes that inherit from game_object without modifying game_object first.


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.

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.


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?
[ dev journal ]
[ current projects' videos ]
[ Zolo Project ]
I'm not mean, I just like to get to the point.

#3 jopy   Members   -  Reputation: 100

Like
0Likes
Like

Posted 21 June 2011 - 03:52 PM


This limits me from adding functions to classes that inherit from game_object without modifying game_object first.


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.

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.


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?


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 ?
+1 for C / C++ / Python

#4 rip-off   Moderators   -  Reputation: 8721

Like
1Likes
Like

Posted 21 June 2011 - 03:55 PM

Solution: Don't store one master list of game objects.

Some approaches:
  • 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:
    • 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.
    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.
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.

#5 jopy   Members   -  Reputation: 100

Like
0Likes
Like

Posted 21 June 2011 - 04:07 PM

Solution: Don't store one master list of game objects.

Some approaches:

  • 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:
    • 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.
    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.
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.


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
+1 for C / C++ / Python




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS