Game Development Reference
In-Depth Information
This is also one of the first steps to a concept called
data-oriented design
(not to be
confused with data-driven design) that looks at how memory is used and structured
to make parallelism much easier while providing performance benefits by using the
CPU cache in a smarter way.
Note that some objects are still represented by classes and are not appropriate for
the
entity/component system
. Things such as screens and settings are usually
specific or sit above this system, and so you would still treat them as you would with
object-oriented design.
If we were to look at the classes defined in the previous design style, we can come
up with the following components:
• Transform
• Health
• Weapon
• Score
• AI/Path (Enemy Controller)
• Input Action
• Texture
• Power-up (Loot/pick-up functionality)
• Enemy Spawner
• Bullet Controller
• Collision Shape
These components may be managed by themselves, or grouped together to make
processing easier. By batching component updates together, you can also make bet-
ter use of the CPU data cache, which can help to improve performance.
You have a choice when creating interaction between different components. You can
have them search for the other components and then directly call them, or you can
implement a messaging system through the entity that allows you to remove all de-
pendencies between the components. Better yet, consider using both methods and
use them where appropriate (for example, use messaging for independent compon-
ents, and direct communication for components that need to know about each oth-
er).
Let's take a look at the same scenario as before, but with this system in place. To
begin with we still have an Input Manager that will detect input from the user; it then
