2
\$\begingroup\$

Usually when I develop a game I will use an architecture like what you see below. What other architectures are popular for simple game development? I'm concerned about having a narrow view of what exists out there for architectures beyond this. Is this an example of component-based architecture? Or is this something else? What would that look like? What alternatives exist?

public abstract class ComponentBase {

    protected final Collection<ComponentBase> subComponents = new LinkedList<ComponentBase>();

    private boolean enableInput;
    private boolean isVisible;

    protected ComponentBase(boolean enableInput, boolean isVisible) {
        this.enableInput = enableInput;
        this.isVisible = isVisible;
    }

   public void render(Graphics2D graphics) {
        for(ComponentBase gameComponent : this.subComponents) {
            if(gameComponent.isVisible()) {
                gameComponent.render(graphics);
            }
        }
    }

    public void input(InputData input) {
        for(ComponentBase gameComponent : this.subComponents) {
            if(gameComponent.inputIsEnabled()) {
                gameComponent.input(input);
            }
        }
    }

    ... getters/setters ...

    public void update(long elapsedTimeMillis) {
        for(ComponentBase gameComponent : this.subComponents) {
            gameComponent.update(elapsedTimeMillis);
        }
    }

}
\$\endgroup\$
2
  • 7
    \$\begingroup\$ Inheritance. Don't feel this is worth a full answer. Traditional "bad" OOP design works perfectly fine for simplistic games. Spend exactly as much effort as it takes to get the job done, and no more. \$\endgroup\$ Nov 13, 2012 at 9:26
  • \$\begingroup\$ I've seen you say things like this in your Digipen videos before Sean - excellent advice. Architectures are a means to an end, and that end is a game. \$\endgroup\$
    – Philip
    Nov 13, 2012 at 16:49

3 Answers 3

5
\$\begingroup\$

Is this an example of component-based architecture? Or is this something else?

No this is a typical game object with multiple responsibilities. It handles everything and calling it component doesn't make it a component as in component based design.

What would that look like?

A component based design? There are multiple questons with great answers already:

The component based architecture could look like this:

public abstract class ComponentBase { 
    public abstract void update(long elapsedTimeMillis);
}

public class PositionComponent extends ComponentBase {
    float x;
    float y;
    float z;
    quaternion r;
}


public class MovementComponent extends ComponentBase {
    float x;
    float y;
    float z;
    quaternion r;

    public void update(long elapsedTimeMillis){
        /* update position component */
    }
}

public class RenderComponent extends ComponentBase {
    RenderModelStructure model;

    public void update(long elapsedTimeMillis){
        /* update the component's engine specifics
        rendering should be done in the render engine  */
    }
}

public class InputComponent extends ComponentBase {

    public void update(long elapsedTimeMillis){
        /* update impacted components */
    }

    public void input(InputData input) {
        /* does whatever input does */
    }
}

What alternatives exist?

The chalkboard design where everything is available for everything to modify. Your approach based on heavy inheritance, and any mix of the different approaches.

There are games written with a very prohiminnent use of arrays, i.e.:

struct position { float x; float y; }
struct movement { float x; float y; }
struct enemy { position* p; movement* m; int shootTime; }
enemy[50] enemies;
\$\endgroup\$
5
\$\begingroup\$

A few methods (patterns? structures? styles?) I've used (excluding the popular version of component-based architecture) in pseudocode:

  • Inheritance: class Player extends Character

  • Composition: class Player { Character baseChar; }

  • Composition with registration: class NPC { Pathfinder P; NPC(){ InitAndRegisterPathfinder( ref P ); } }

  • Interface: class Player { Renderable R; Player(){ R = CreateRenderable(); } }

  • Internal implementation of interface: class Player extends Renderable { Player(){ RegisterRenderable( ref this ); } }

  • Quick & dirty composition: class World { Vec3 playerPos; ... } or even function Game(){ Vec3 playerPos; while(true){...} }

All of these have their uses. To dismiss any in favor of some imagined "supreme power of component-based architecture" would just mean that one day you'll wonder how the other guy made his game so quickly.

\$\endgroup\$
1
\$\begingroup\$

This will not be a full answer.

In my opinion there are no simple games. Every game is sophisticated in her own way.

This is not an example of component based architecture. This a polymorphic design. To be a component based design it need's components!

I am not very experienced in game development - but I can't see a better alternative.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .