Contents

Next: Introduction Up: Data-Oriented Design Previous: Data-Oriented Design

New version now available here at www.dataorienteddesign.com/dodbook/

This page is from the beta release of the Data-Oriented Design book. There are errors, spelling and factual, and this page is only kept for purposes of maintaining old links.

• Data-Oriented Design
  • It's all about the data
  • Data is not the problem domain
  • Data and Statistics
  • Data changes
  • How is data formed?
  • What can provide a computational framework for such complex data?
  
  
• Existence Based Processing
  • Why use an if
  • Don't use booleans
  • Don't use enums
  • Prelude to polymorphism
  • Dynamic runtime polymorphism
  • Event handling
  
  
• Component Based Objects
  • Components in the wild
  • Away from the hierarchy
  • Towards Managers
  • There is no Entity
  
  
• Hierarchical Level-of-Detail and Implicit-state
  • Existence from Null to Infinity
  • Mementos
  • JIT Data Generation
  • Alternative Axes
  
  
• Condition Tables
  • Building Questions
  • Flip it on its head
  • Logging decisions for debug: Making answers talk for themselves
  • Branching without branching
  
  
• Finite State Machines
  • Tables as States
  • Implementing Transitions
  • Condition tables as Triggers
  • Conditions as Events
  
  
• Searching
  • Indexes
  • data-oriented Lookup
  • Finding lowest or highest is a sorting problem
  • Finding random is a hash/tree issue
  
  
• Sorting
  • Do you need to?
  • Maintain by insertion sort or parallel merge sort
  • Sorting for your platfom
  
  
• Relational Databases
  • Normalisation
    • 1^st Normal Form
    • Reflections
    • Domain Key / Knowledge
    • All Normal Forms
    • Sum up
  • Implicit Entities
  • Components imply entities
  • Cosmic Hierarchies
  • Structs of Arrays
  • Stream Processing
  • Beautiful Homogeneity
  
  
• Optimisations and Implementations
  • Tables
  • Transforms
  • Spatial sets for collisions
  • Lazy Evaluation for the masses
  • Not getting what you didn't ask for
  • Varying Length Sets
  • Bit twiddling decision tables
  • Joins as intersections
  • Data driven techniques
  
  
• Concurrency
  • What it means to be thread-safe
  • Inherently concurrent operations
  • Queues as gateways, and "Now"
  
  
• In Practice
  • Data-manipulation
    • The Cube
    • Rendering order
    • Keeping track of damage
  • Game entities
    • Converting an object oriented player
    • People don't really exist.
    • Lazy evaluation molasses
    • Component oriented design
  
  
• Maintenance and reuse
  • Debugging
    • Lifetimes
    • Avoiding pointers
    • Bad State
  • Reusability
  • Unit Testing
  • Refactoring
  
  
• Design Patterns
  • What caused design patterns
  • Data-Oriented Design Patterns
    • A to B transform
    • In place transform
    • Generative transform
    • Sorted Table
    • Multi sorted table
    • Gatherer
    • Tasker
    • Dispatcher
  • Existing design patterns
    • Abstract Factories
    • Builder
    • Factory Method
    • Prototype
    • Singleton
    • Adapter
    • Bridge
    • Composite
    • Decorator
    • Façade
    • Flyweight
    • Proxy
    • Chain Of Responsibility
    • Command
    • Interpreter
    • Iterator
    • Mediator
    • Memento
    • Null Object
    • Observer
    • State
    • Strategy
    • Template Method
    • Visitor
  • Locking out anti-patterns
    • Abstraction Inversion
    • Acme Pattern / God Class
    • CObject / Cosmic Hierarchy
    • Hidden Requirements
    • Stovepipe
  • Game Development Patterns
  
  
• What's wrong?
  • The Harm
  • Mapping the problem
  • Internalised state
  • Hierarchical design
  • Divions of labour
  • Reusable generic code
  
  
• Looking at hardware
  • Sequential data
  • Deep Pipes
  • Microcode: virtually function calls.
  • Single Instruction Multiple Data
  • Predictable instructions
  
  
• Future
  • Parallel processing
  • Distributed computing
  • Runtime hardware configuration
  • Data centric development in hardware design

---

Richard Fabian 2013-06-25