Public Group

Storning/Managing game objects (2D)

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

Recommended Posts

Alright, first topic here, hope I'll be able to get some help. A little bit of background: I have almost no formal programming experience, so I feel like there's a lot of theoretical stuff that I don't know.
I'm working on throwing together a simple 2D game engine. I'm working in C++ and I've already produced a thrown together system using SFML"]http://www.sfml-dev.org and Box2D"]http://box2d.org/ that allows me to have sprites on the screen, move then around, collide them, etc.

My question is more of a general plea for advice: currently in order to handle all of the objects in a given control system (call it a "level") I've created a class called Object, and three classes that inherit from it, PlayerObject, MobileObject, and ImmobileObject. Then, to store all of the objects in a given level I create a vector of Objects that I then fill with with every object in the level. Then, every frame/refresh I iterate through that vector calling the universal "Draw" function that the base class Object has.

There's a bit more. My Object vector actually contains one PlayerObject, and two more vectors composed of MobileObjects and ImmobileObjects. The reason for this is that if I have, say, my gravity function, its a waste to preform a isAffectedbyGravity check on all immobile objects, so by organizing them into sub-vectors I can only call gravity on PlayerObject and MobileObjects. I do something similar with collision detection, so that I don't check every immobile object against every other immobile object for collisions.

So basically...what do people think of what I've outlined above? Is it laughably incorrect? On the right track but with room for improvement? Anything anyone can offer is great.

Share on other sites
First, you should use a own class for the vector. Call it ObjectManager or SceneManager.

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

There's a bit more. My Object vector actually contains one PlayerObject, and two more vectors composed of MobileObjects and ImmobileObjects. The reason for this is that if I have, say, my gravity function, its a waste to preform a isAffectedbyGravity check on all immobile objects, so by organizing them into sub-vectors I can only call gravity on PlayerObject and MobileObjects. I do something similar with collision detection, so that I don't check every immobile object against every other immobile object for collisions.[/font][/quote] You should use a hierarchy, like a tree or a graph for this. For example: class Node : public Object{ Node *parent; Node **pChildrens; void render() { //i dont know if you are using matrices, or position vector but here you should combine the one from your parent and that //then call render from all childrens so you only have to call render once in your program }; }  I hope that can help you. Cheers!

Share on other sites
Rolling your own data type is simply a silly thing to do, don't do that, use the facilities that C++ provides you. If you need to track via name or ID a map<> is probably the perfect type. If on the other hand you don't care about accessing items individually, a vector is a good fit. Only if you are doing culling or sorting does a more advanced type such as a tree or doubly linked list make sense. Even then, if you have to use a more advanced type, list exists. Should you need something more advanced boost is there for you. Of course I'm not saying learning algorithms yourself aren't a good idea, it is a very good practice to use, but in production code, use the code that has been vetted by thousands instead of rolling your own unless you absolutely have to.

Your basic premise makes sense. Check out this part of my over-engineered Pong tutorial as it introduces a common base class "VisibleGameObject" which is akin to your Object class. ( By the way, if you name your class Object I am going to come to your house and beat you with a trout! ). The player paddle, game ball and enemy paddle are all derived from VisibleGameObject. Then there is a class presented here called GameObjectManager which is essentially a small wrapper around a map<VisibleGameObject>, which handles the Update and Draw calls to each VisibleGameObject. There are some people that will recoil and hiss like a vampire presented with garlic at calling something a _______Manager, but hey, if it looks like a duck, quacks like a duck and just shit on your windshield, call it what it is.

So basically, that tutorial basically introduces exactly the class hierarchy you are describing. As an added benefit, it is implemented in SFML.

Share on other sites
It might help for you to take a look at my old blog (in my sig, the blogspot one). In it I detail making a 2d game using SFML, chipmunk-physics (a 2d-physics engine, like Box2D). While my methods aren't always the best, it should give you an idea of how to structure a game, as well as using XML to store data.

• Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 16
• 11
• 23
• 42
• 75