Jonathan Blow on Entity Component Systems

Here are detailed notes from the transcript:

---

Detailed Notes from Transcript

Main Topics Discussed:

1. Software Architecture for Game Entities: The core discussion revolves around different approaches to structuring game entities in a software system, specifically contrasting a "fat base entity" approach with component-based systems like Entity Component System (ECS).
2. Trade-offs between Memory Usage and Development Complexity: The speaker analyzes the impact of storing redundant data in a "fat" base entity versus the complexity introduced by trying to avoid that redundancy.
3. Object-Oriented (OO) vs. Function-Based Programming Paradigms: The transcript touches on how different programming philosophies (especially regarding methods attached to objects) influence design decisions and perceived complexity.
4. Efficiency and Pragmatism in Game Development: A recurring theme is the importance of choosing simpler, more manageable solutions over theoretically "purer" but overly complex ones, especially when the practical benefits are minimal.

Key Points and Arguments:

• Speaker's Preferred Entity Hierarchy ("Fat Base Entity"):

  • Consists of a single "base entity" from which all other entities derive directly (one level of derived entities).
  • Described as a "tree with one root and then all the nodes are flat" and "very simple."
  • Advantage: Simplicity, ease of serialization, and overall manageability.

• Addressing Redundant Data (The "Charmed By" Example):

  • Problem: The base entity contains members like charmed by that are only relevant to a small subset of entities (e.g., monsters and players), meaning all entities (even non-interactive background meshes) carry this data.
  • Argument Against it Being "Terrible" (Memory Cost):
    • The memory cost of this redundancy is negligible on modern hardware.
    • Calculated waste: 200,000 entities * 8 bytes/entity = 1.6 megabytes.
    • Conclusion: "Trivial amount of memory on a modern computer," "who cares?"
    • The speaker acknowledges it could be factored out but hasn't bothered due to its low priority and minimal impact.
  • Argument Against it Being "Terrible" (Code Complication):
    • The complexity depends on programming style.
    • Object-Oriented View: If objects must have methods, then placing such data in a base class leads to "conflicting methods" and dispatch issues, making it messy.
    • Speaker's View (Function-Based): If data is operated on by standalone functions (not methods), then a simple if statement to check an entity's type (e.g., is it a monster or player?) is "very simple and understandable."
    • Conclusion: An OO mindset might prevent developers from seeing the simplicity of a function-based approach for handling "fat" entities.

• Critique of Entity Component Systems (ECS):

  • ECS aims to avoid storing redundant data (which is a primary argument for its use).
  • Counter-argument: Achieving this non-redundancy in ECS often introduces "so much complexity."
  • Conclusion: This complexity is "not worth it" when compared to the minimal practical benefits (like trivial memory savings). "Your life is short."

Important Facts or Data Mentioned:

• Entity Hierarchy Structure: Base entity with only one level of derived entities.
• Example Redundant Data: charmed by (4-8 bytes).
• Estimated Max Entities: 200,000 in an overworld.
• Calculated Memory Waste: 200,000 entities * 8 bytes = 1.6 megabytes.
• Other "Fat" Base Entity Data: animation player, animation graph, undoble entity data.
• Robot Reference: A "$1600 wheeled Chinese robot" (Unitree), noted for having a flat top "designed to have things mounted on top."

Conclusions or Recommendations:

• Embrace the "Fat Base Entity": The speaker strongly advocates for using a "fat base entity" design, even if it means storing some redundant data.
• Prioritize Simplicity over Theoretical Purity: The minimal memory savings achieved by complex architectural patterns like ECS do not justify the added development complexity and time investment.
• "It totally doesn't matter": The memory inefficiency of a "fat base entity" is a non-issue in the context of modern computing resources and game development priorities.
• Factor Out for Future Maintainability, Not Memory: If refactoring occurs, it should be for long-term maintainability or future game versions, not out of concern for memory savings.
• "Don't do ECS": Explicitly advises against using ECS due to its perceived unnecessary complexity.
• "Life is short": A philosophical underpinning for choosing simpler, more pragmatic solutions.
• (Humorous/Satirical) "Buy a shotgun": A final, tongue-in-cheek recommendation related to the robot discussion, implicitly reinforcing the "life is short, focus on what matters" sentiment over complex software design.