Game Object Design

oisin
  • Game Object Design oisin

    I'm having a problem with the way I designed my first simple game in C++.

    I have GameObject (abstract class) and ObjectA which inherits the update() and draw() methods from GameObject.

    My main loop contains a linked list of GameObject*, and while that list is not empty it cycles through it, calling update on each one.

    Up until this point, I thought the design was standard(?) and would work.

    However, when I call update on ObjectA() I run into two problems:

    • ObjectA can die which messes up the list, which in turn throws off the loop in main.
    • ObjectA can spawn more ObjectA's but these are local scope and the update() goes out of scope, creating problems in main's list of GameObjects.

    I think my design if alright, but I'm having such problems with segmentation faults that there must be something seriously wrong with at least one part of my implementation. If anyone could point out any serious mistakes or simple examples of this being done (or even alternative designs) then I would greatly appreciate it!

  • First off, don't use linked lists.

    Second, your design should work, in theory. For the dying problem, an easy solution is to just have some kind of flag on your GameObject class that says whether or not the object is dead. Just set it in your concrete classes' update method when appropriate. Then after all of your updates are complete, remove the dead objects from the object list.

    So in theory something like this (excuse my C++ it's been a while):

    for_each( m_allEntites.begin(), m_allEntites.end(), mem_fun( &GameObject::update ) );
    remove_if( m_allEntites.begin(), m_allEntites.end(), mem_fun( &GameObject::isDead ) );
    for_each( m_allEntites.begin(), m_allEntites.end(), mem_fun( &GameObject::draw ) );
    

    Third, for your "new game objects" problem. What you want to do is use new on the ObjectA objects you create. If you can't modify the list while you're iterating over it, an easy solution is to create a temporary list (or vector, whatever) with the new objects you've created. Then when you're done with update, add the new objects to the list of all objects. A naive solution would just be that all GameObjects know about the class that contains them, but I wouldn't worry about the coupling that imposes at this point in time until you figure out the basics. So in your class that contains the list of all objects, and modifying the above structure, you can do something like this:

    for_each( m_allEntites.begin(), m_allEntites.end(), mem_fun( &GameObject::update ) );
    m_allEntites.insert( m_allEntities.end(), m_newEntities.begin(), m_newEntites.end() );
    m_newEntites.clear();
    remove_if( m_allEntites.begin(), m_allEntites.end(), mem_fun( &GameObject::isDead ) );
    for_each( m_allEntites.begin(), m_allEntites.end(), mem_fun( &GameObject::draw ) );
    

    Edit: Just realized previous code would leak dead objects. I'm used to using ptr_vector instead of standard vector to maintain strict ownership rules. Using a standard vector you'd want to iterate over the list and delete dead objects. A common pattern I've used in the past was to also set their pointer to null then do a remove_if on null objects. Or you could do something fancy and keep GameObjects around in a bucket pattern to avoid allocations if that's the route you wanted to go down.

  • The solution is to iterate in reverse from back to front. That way, if you: 1. Add things to the end of the list, it won't get iterated upon 2. The currently-iterated thing dies, the loop can still continue as normal

    If I were you, I'd use a vector class and iterate backwards using numeric indices. (e.g. for int i = things.size() - 1; i >= 0; -- i)

Tags
c++ objects
Related questions and answers
  • I'm creating a component-based game object system. Some tips: GameObject is simply a list of Components. There are GameSubsystems. For example, rendering, physics etc. Each GameSubsystem contains... GameSubsystems) can implement registerComponent(Component*). pro. Components and GameSubystems know nothing about each other. con. In C++ it would look like ugly and slow typeid-switch... a decision which Components to register (and how to organize them). For example, GameSubsystemRender can register Renderable Components. pro. Components know nothing about how they are used. Low

  • Alright so i'm making a vertical side scroller where you are an '8' character traveling downward while avoiding my randomly generated walls (the "generation" function) on the left and right sides... until you pop out into an open space, known as a ' ' (space) character. You lose one life for each INITIAL collision with the X wall, and do not lose another until you have popped out and been freed... collided with are deleted. However I am having trouble getting the INITIAL COLLISION with the wall to be detected correctly. the result is the playe incorrectly losing 4 lives after hitting 1 wall

  • Since building a game is not about 2D anymore, I just want to build a list of the (not necessarily best, but good enough) open source software available to make games. I prefer to put emphasis on libraries that insist on specializing on one part of what makes a game (like Ogre does for graphics, and OpenSteer does for steering), rather than engines/libraries that try to feature a lot... (plugin for Ogre3d) http://sourceforge.net/projects/nxogre/ Bullet Feel free to update this list and/or add categories.

  • I am studying entity indexed components and came up with a naive C++ implementation which just iterates over all entity "hash tables" and applies update/delete/insert functions in place. I'm having trouble maintaining a logical view of the game world (i.e. updates shouldn't be visible while iterating) and there is no attempt at maintaining spatial or temporal coherence of data. I wonder whether... components total. Or is this even feasible? How much I can accomplish with this approach? In essence I want to be able to do something like this with reasonable efficiency: moving_update(DB

  • controls easy to set up (i'm using SFML and Box2D at the moment) I don't want to re-invent things like buttons, arrows being placed wherever the mouse is located, and more game specific items... that.... Allows easy setup of controls for a game Makes events like clicking and holding on an object easy to setup, as so objects can be dragged around afterward Are there any simple libraries or resources out there that i can use to avoid spending much of my time coding these now standard input devices/tecniques?

  • second and 75 frame draws per second. Up until now, it is in the physics update routine that I do the collision detection and response. Your ship can collide with a rock. Your photons (bullets) can... out of the update routine and into the draw routine, seeing as I will be drawing these interpolated frames ? Bear in mind, my highest priority goal is to make this networked: multiple player ships... a problem with smoothness. If I reduce my physics updates to 25 per second which I have only done as an experiment then it is a bit jerky. But the game easily runs at higher rates than that so there may

  • I'm looking into designing and implementing an online RPG (or more accurately, redesigning an existing piece of server software). One of the problems is that of managing visibility. Update data... or easier way? If it can be multithreaded that would obviously be better, and the less main-thread calculation the better. (For anyone wondering, the project is in C++). ... problem is that if you had to compare all the players every time an update is sent, it would just take way too long as the number of players scales (think up to a few thousand players per map and each

  • not seem to have joystick input support, which would require that SDL or some other library also be used. So my question can be summed up as this: What is the best way to get SVG and joystick...I'm looking into building a cross-platform opensource 2D RPG style game engine for ChaiScript. I want to be able to do all of the graphics with SVG and need joystick input. I also need the libraries I use to be opensource and compatible with the BSD license. I'm familiar with allegro, ClanLib, and SDL. As far as I can tell, none of these libraries have built in or obvious integration for SVG

  • C++ application. Entities can be defined in an XML file (the IA part in a lua or python file). The main loop doesn't care a lot about entities: it only manages components. The software design should... remove_component(C* c) { components.at<C>() = 0; } void serialize(filestream, op) { /* Serialize all componets*/ } ... }; std::list<Entity*> entity_list; With this design I can get #1...I'm writing a shooter (like 1942, classic 2D graphics) and I'd like to use a component based approch. So far I thought about the following design: Each game element (airship, projectile, powerup

Data information