Please enable JavaScript.

Coggle requires JavaScript to display documents.

Game Programming Patterns (Design (Command (Similar names (Callback, First…

- - - - Encapsulate a request as an object
      - Make method call real / tangible
      - Take some concept / logic / operation and turn it into a piece of data
    - - Define functionality as data
      - Track, Queue, or Log Requests
      - Support undo and redo operations
      - Replay a game by simply issuing all the same commands at the right times
    - - Callback
      - First-class function
      - Function pointer
      - Closure
      - Partially applied function
    - - Configuring Input
        
        Implementation
        
        Create sub-classes for each of the different game actions.
        
        Input handler would have pointers to commands for each button and just delegate to the commands.
        
        If there is a purpose for a button to do nothing a command which does nothing can be used, this pattern is called "NULL Object".
        
        Define a base class that represents a trigger-able game command.
        
        Description
        
        Allow for input buttons to change what they affect.
      - Directions for Actors
        
        Input Manager
        
        Input handler would now return a command when a button is pressed because it can't execute the command immediately without knowing the current actor.
        
        A class that knows the current actor can then call on the input handler for a command and execute the command passing the current actor.
        
        Allows the player to control any actor in the game by just changing the actor passed to the command.
        
        Require that a command receives an actor to execute on.
        
        AI implecations
        
        This paves the road for an AI class that simply emits command objects.
        
        Allows for AI modules for different actors or mix and match for different kinds of behavior.
        
        Akin to a queue or stream of commands. #
        
        Description
        
        Some code produces commands and places them in the stream. Other code consumes commands and invokes them.
      - Undo and Redo
        
        Description
        
        This is the most will-known use of this pattern.
        
        Each command will not only know what it changed but it will also remember how to reverse the change.
        
        This is different from the abstraction accomplished by "Directions for Actors" in that the command needs to know which actor its changing.
        
        Implementation
        
        Require that a command has knowledge of all changes.
        
        Define another operation each command class needs to implement "undo()".
        
        The command is responsible for remembering the previous game state.
        
        Control
        
        To allow the player to undo, we keep the previous command or a history of commands.
        
        To allow redo simply execute the next command as normal.
        
        If a new command is made after one or multiple undo operations then discard all commands in the redo history.
        
        Considerations
        
        The Memento pattern, but since commands tend to modify only a small part of an object's state, to snapshot the rest of its data seams like a waste of memory.
        
        Persistent data structures are another option. Every modification to an object returns a new one leaving the original unchanged. Through clever implementation these new objects share data with the previous ones so its much cheaper than cloning the entire object.
        
        Using a persistent data structure, each command stores a reference to the object before the command was performed, and undo just means switching back to the old object.
    - - Lots of different command classes can be managed by having a good base command class. The Execute method of the command class
      - An Object may respond to a command, or it may decide to pawn it off on some subordinate object. If this is true its called the "Chain of Responsibility pattern".
      - Some commands are stateless chunks of pure behavior. In cases like that, having more than one instance of that class wastes memory since all instances are equivalent. The Flyweight pattern addresses this. Stateless chunks of pure behavior
  - - - Use sharing to support large numbers of fine-grained objects efficiently