Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

This days I'm refactoring code and one of the things I want to improve is my entity manager code. More precisely, the update funcion where entities are updated. My engine is a 2D tile based engine that I'm using for an iphone game. The idea I had was to have the entity update splitted in several tasks because I'm willing to move to component based entities when I have the time. This is a Physic task, a collision detection task, AI task, etc...

For long time I have been using a simple update() function for my entity update that was called by the entity manager in a loop. Now I have come across another way to do it (in the end it is the same) but gives me some advantages like for example differnt ticks for the different tasks (Physics can run at a differnt refresh rate than collisions, etc...)

Here is the source code. I would be really happy if anyone could comment, give opinions, or improve it. Sorry ti is ObjC but I think it is pretty easy to understand:

//Run the update process o nall entities.
for(int i=0; i< numGameObjects;++i)
{
    GameObject* go=_entities[i];

    //If this game object was marked to be delted don't do any process with it.
    //It will be released when update loop is finished.
    if(! [go isToBeDeleted])
    {
        //Player does its physics (Movement, etc...)
                    //We save old position to let the onMapCollision know
                    //The previous position before physics were applied.
        CGPoint oldPos=[go position];
        [go doPhysics];

        if([go collisionEnabled])
        {   
            //Check collisions against map
            CollisionMask collisionMask=[go collisionMask];
            if(collisionMask & MapEntity)
            {
                bool collision=[self checkEntityVsMapCollision:go];
                if(collision==true)
                    [go onMapCollision:oldPos];
            }

            //Check collisions against other entities (just the ones that have not been checked previously)
            for(int j=i+1; j < numGameObjects; ++j)
            {
                GameObject* otherGO= _entities[j];
                EntityType type=[go type];
                if( (collisionMask & type) && [go collidesWith:otherGO])
                {
                    [go onEntityCollision:otherGO];
                    [otherGO onEntityCollision:go];
                }
            }
        }

        //Execute AI for this game object
        [go doLogic];
    }
}

There could be some sintactical errors in the code but I just wanted to show the idea. Sorry for the long question, but I thought I had to explain everything as clear as I could.

Thanks in advance.

share|improve this question
    
Your accept rate is low. –  Den Dec 15 '11 at 16:23
    
Solved. Sorry for the inconvenience. –  Notbad Dec 15 '11 at 18:29
add comment

2 Answers 2

up vote 2 down vote accepted

My entity system lib uses messages for updating. Each frame a TickMessage is sent. Entity systems can register themselves to the tick message, and can do that with a "priority": earliest, early, default, late. The registrants are called in the order of their priority. This way, the physics system can run before the rendering system but after the input system and so on. The tick message contains the time since the game started, the delta timew since the last frame and the unix timestamp.

This approach is a little more complicated than calling a virtual update method on each system, but I think it is worth it. Entity systems can deregister themselves when they have nothing to do, which saves a lot of computing power.

share|improve this answer
    
Haven't think about it that way. Thanks a lot for the tip. I will take it into account. –  Notbad Dec 15 '11 at 22:00
add comment

I would start with extracting 'entity systems' based on kind of update:

PhysicsSystem, CollisionSystem, AiSystem

After some further refactoring you might end up with a class like EntitySystemsManager which will have a method Update that loops through collection of systems updating those of them that are enabled.

share|improve this answer
    
Sounds interesting. I think I first thought about something like this. Having a manager for every component in my system and later run update on managers that run update on its homogeneous components. What do you think about the method I exposed? –  Notbad Dec 15 '11 at 18:32
    
@Notbad: "method I exposed" - do you mean your original code? –  Den Dec 16 '11 at 10:04
    
Yes. Mainly the way things are splitted and execution order. –  Notbad Dec 16 '11 at 14:24
    
It looks clean to me. –  Den Dec 16 '11 at 14:53
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.