Jump to content
  • Advertisement
  • Remove ads and support GameDev.net for only $3. Learn more: The New GDNet+: No Ads!

  • 06/19/01 10:18 PM
    Sign in to follow this  

    Controller

    General and Gameplay Programming

    Myopic Rhino
    (C) 2000 - Zachary Booth Simpson. Copied with permission from http://www.mine-control.com/zack. If you find any of this work useful, please sign Zack's guest book: http://www.mine-cont...i/gbook-zbs.cgi.


    [size="5"]Intent
    [bquote]Update a Model's state based on circumstance.[/bquote]

    [size="5"]Problem
    [bquote]Controllers implement the rules of a game. They determine how objects behave given a circumstance, and isolate these rules from the objects themselves. This makes both the controllers and models more reusable and maintainable.[/bquote]

    [size="5"]Solution
    [bquote]Controllers relate to Models and Views as follows:
    • Models are read-writeable by Controllers.
    • Controllers are created and destroyed by Models, but are otherwise invisible.
    • Views are invisible to Controllers and vice-versa.
    Controllers are often associated with only one model instance. For example: animation, AI, pathfinding. In these cases the controller instance is usually created and destroyed synchronously with the associated model.

    Some Controllers inherently have more than one associated Model. For example: multi-body physics, target tracking (heat seeking missiles, etc). These controllers often maintain Model references which must be notified / garbage collected when the referenced object dies. This is called the "model death problem". The creation and deletion of these multi-owner controllers is usually done by some primary owner.

    Controllers are often implemented as "processes" in a mini cooperative multi-tasking kernel. (See Mini-kernel) but may also be implemented as "hard wired updates" in the main loop, especially for large multi-model controllers like physics.

    Some simple Controllers are stateless. For example, a homing missile controller may just compute the direction to the target and apply force as necessary. Most controllers, however, are state-aware. For example, an animation tracks progress through the animation and changes states accordingly; e.g. if (frame > 10) state = STOP_WALKING.

    State-aware controllers often become significantly complicated with large switch statements. (See State Machine Controller.)[/bquote]
    [size="5"]Structure
    [bquote]Not available at this time.[/bquote]

    [size="5"]Issues and Risks
    [bquote]None at this time.[/bquote]

    [size="5"]Related Patterns
    [bquote]Mini-kernels aggregate Controllers, giving each controller some time to work. Controllers modify Model's states.

    Views may translate Model state with an Appearance Map.

    Complicated state-aware controllers may use a Controller State Machine.[/bquote]


      Report Article
    Sign in to follow this  


    User Feedback




    There are no comments to display.




    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!