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

    Mini-kernel

    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]Provide each Controller with a chance to execute once per game frame.[/bquote]

    [size="5"]Problem
    [bquote]Without a mini-kernel, Model objects are typically updated by a set of hard-wired controller functions called from the main loop. For example:

    void updateWorld()
    {
    for( int i=0; i < numTanks; i++ )
    {
    if( tanks )
    {
    updateTankPhysics( tanks );
    updateTankAI( tanks );
    }
    }

    for( i=0; i < numSoldiers; i++ )
    {
    ... etc ...
    }
    This style of updating requires that any new controller be hardwired into the update calls, which reduces encapsulation and increases maintenance.

    An operating-system-like method is needed where controllers can be created and removed dynamically as needed.[/bquote]
    [size="5"]Solution
    [bquote]A base controller class is created which is the super-class of all controllers. A list of controller pointers is maintained. Each game frame, the mini-kernel (called from the main loop) gives each controller a chance to execute by calling a virtual "update" method. This is a cooperative multi-tasking system. For example:

    class BaseController {
    virtual void update() = 0;
    }

    class MissileController : BaseController {
    Model &missle, ?
    virtual void update() {
    missile.pos += missile.vel;
    missile.vel += (target.pos - missile.pos).norm() * missAcc;
    }
    }

    void miniKernelDoAllControllers() {
    foreach controller in list { controller.update(); }
    }
    Note that all controllers update calls are non-blocking; they are expected to do some actions quickly and return control back to the mini-kernel.

    It is often necessary to ensure that some controllers always run before others. For example, user interface may need to run before animation or physics to ensure that mouse clicks are interpreted with respect to the correct frame of reference. This can implemented with a priority number for each controller; the mini-kernel either sorts the controller pointers once per frame by priority or ensures that the list remains in sorted order.

    The mini-kernel may be implemented to handle some common controller bookkeeping. For example, the kernel might update a counter in each controller so that the controller can determine its age quickly. Or, the kernel might monitor per controller sleep fields to simplify timing much like the sleep() function in Unix or Win32.

    Controllers are frequently "attached" to Model objects though some sort of dependency system. This dependency ensures that the controller is garbage collected along with the associated model when it dies. This may involve some cooperation on the part of the mini-kernel.[/bquote]
    [size="5"]Structure
    [bquote]Not available at this time.[/bquote]

    [size="5"]Examples
    [bquote]None at this time.[/bquote]

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

    [size="5"]Related Patterns
    [bquote]Mini-kernels are aggregations of Controllers.[/bquote]

    [size="5"]Uses and References
    [bquote]Thanks to Tony Zurovec.[/bquote]


      Report Article
    Sign in to follow this  


    User Feedback

    Create an account or sign in to leave a review

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

    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

    There are no reviews to display.