程序代写代做代考 flex COMP8551 Entity component systems
COMP8551 Entity component systems
Borna Noureddin, Ph.D.
Entity Component Systems
COMP 8851
Object-oriented games
• Everything (player, enemy, tank, bullet, light, sound effect,
etc) defined by its own class
• Often great deal of similarity between some classes:
inheritance (eg, Tank and Car can derive from Vehicle
class)
• Intuitive and relatively effective
• Can add Truck by inheriting from Vehicle
• Vehicle might inherit from PhysicalObject, as can Projectile
© Borna Noureddin
Object-oriented games
• Design requires detailed design of class hierarchy
• Hierarchy of increasingly abstract classes
• If hierarchy planned out well before implementation, can
build large, complex game leveraging inheritance
• But, the deeper the class hierarchy, the more brittle and
fragile it becomes:
• Requirements change after implementation begins
• Need to add/remove functionality to some abstract classes
• Changes will affect all subclasses (even if they don’t actually need changes)
• End up with messy code additions pushed up towards root
© Borna Noureddin
Entity component games
• Core principles of good software design is modularity
• Many benefits of modularity, including flexibility
• Can replace one piece without having to change
everything, especially if rest of system talks to it the same
way (i.e., new replacement piece conforms to same
interface)
© Borna Noureddin
Entity component games
• Entity represents concrete “thing” (e.g., Tank)
• has no Tank-specific logic
• actually barely any logic at all (really just an ID)
• Real magic: the components it contains
• Component is a module of functionality (attribute?)
• things that Entities have (e.g., Position, Velocity, RenderableMesh,
PhysicalBody, etc.)
• Entity little more than bag of Components
• Entity has no explicit knowledge of what parts it contains
• => All entities can be treated the same way by the rest of
the game
© Borna Noureddin
Entity component games
• Possible because components take care of themselves,
regardless of which entity they belong to
• Example:
• RenderableMesh component contains capability to render a 3D model
• Model assigned to component
• Component assigned to entity
• Entity calls generic Draw() function on all its components, without needing
to know what it does
• RenderableMesh draws itself to display
• All the entity needs to do is call some generic update
function on each of its components each frame, and each
component will do its own thing © Borna Noureddin
Entity component games – Pros
• Components are generic, perform single role, same way,
regardless of parent entity
• RenderableMesh of a Tank object would draw itself the same way as
that of a Car object
• Only difference: shape of mesh assigned to each component
• Different types of entities can be manufactured easily by
plugging different reusable components into empty entity
© Borna Noureddin
Entity component games – Pros
• Great for maintaining flexibility during and after
development
• Changes to entities typically involve changing 1 or 2 components in
isolation
• No need to change any unrelated components or pollute other
entities
• New functionality can be added with independent addition of new
components
© Borna Noureddin
Entity component games – Cons
• There are inherent relationships between components
which requires them to be coupled in some way or other
• E.g., RenderableMeshknows how to render, but not where
without consulting Position component
© Borna Noureddin
Entity component games – Cons
• Velocity component not much good without being able to
update Position component
• Possible solution: push ‘shared data’ up into the Entity itself
• all components can read and write to position variable
• leads to analogous problem to that of the traditional OO hierarchy:
slippery slope
• movement also needs to know how much health entity has
• either communicate with Health component or push health up into
entity
• and so on….
© Borna Noureddin
Entity component games – Cons
• Another solution: allow components to hold references to
each other and communicate directly
• Multiple drawbacks
• couples components very tightly (difficult to reuse)
• references need to be assigned when entity is created, but without
entity’s direct intervention (non-trivial problem)
• could implement some elaborate system of runtime inter-
component dependency resolution and injection: extremely
complex
© Borna Noureddin
Entity component games – Cons
• Alternative: attach message dispatching system to each
entity
• Allows components to fire events when something
interesting happens, and handle other events of interest
fired by other components
• Decouples components (nice), but comes at cost of
increased complexity and persistent performance penalty
© Borna Noureddin
Entity component games – Cons
• Even if all components hooked up and working together,
completely encapsulating logic related to each component
fraught with danger of components becoming bloated with
functionality
• Theoretically, Physics component should handle all physical
interaction between its parent entity and rest of the world, but
does the knowledge of the rest of the world really belong in a
component?
• Maybe split out physics calculations into a centralized physics
manager: which components have logic and which don’t, and
how much?
© Borna Noureddin
