0
\$\begingroup\$

So I'm making a game engine for a game I'm making - the game is a 2D tile-based game

I've implemented a gameobject-component style for the engine, for decoupling reasons

However, every frame, the engine iterates through every gameobject, and calls the update method of every component on that gameobject - as it's a tile-based game, every tile is a gameobject, which means that that update loop could go through several thousand gameobjects every frame. Add into that the fact that each gameobject could have multiple components (transform component containing location/rotation info, renderer component, collider component etc), and a hell of a lot of time is spent in that loop. This is only magnified by the fact that the game is a mobile game, and as such the processing power isn't as great as on a desktop

Any ideas on algorithms/programming styles/design styles that would help to minimise this performance sinkhole please?

\$\endgroup\$

2 Answers 2

Reset to default
0
\$\begingroup\$

In our engine, the component class only manages the scene graph, dirty state management and notifying the root scene that the scene graph has changed.. components may implement IUpdatable and IRenderable as needed, and the root scene tracks any graph changes and maintains lists of updatable and renderable components to process during a frame update. This interface based technique will also be used later for other "lifecycle" events such as IPhysicsUpdatable. Overall the result is we have a reasonably short list of updatables, another of renderables, and making calls on these 2 lists in order (updates then renders) handles rendering our scene graph very quickly :)

\$\endgroup\$
1
  • \$\begingroup\$ Thanks - didn't think of this - this seems to be the best of going about it :-) \$\endgroup\$ Commented Sep 14, 2014 at 11:33
0
\$\begingroup\$

Normally different sub-engines take care of ticking their associated components in game objects. For example your rendering engine ticks only the rendering components of game objects that are visible on the screen, while your AI/physics engine could tick what's on the screen + outside with some decreasing frequency based on the distance. You don't tick all the components in the world every frame because like you said that gets expensive for larger worlds.

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.