Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've been building a toolkit for my game and recently decided I needed a history system as well as clean out the mountain of event handlers building up in my code. To do this, I've started using something I refer to as "contexts" to separate out the code. Each context refers to, essentially, different tools (SelectionContext, DrawTerrainContext, etc.) and they also contain "actions" which are added/removed from the history stack.

Some pseudo-code:

public abstract class Context
    public abstract void Initialize();
    public abstract void Destroy();
    public virtual void Update();

public interface IAction
    void Execute();
    void Undo();

public class SelectionContext : Context
    public override void Initialiize() { // Stuff }
    public override void Destroy() { // More stuff }
    public override void Update()
        if(mouseDown && noSelection)
        else if(mouseDown && !noSelection)
        else if(!mouseDown && !noSelection)

    public void startSelection() { // Create "SelectionAction" object }
    public void expandSelection() { // Update data in "SelectionAction" }
    public void finishSelection() { // Execute and push "SelectionAction" to history }

    private class SelectionAction : IAction
        private List<object> _oldSelection;
        private List<object> _newSelection;

        public SelectionAction() { // Save the current selection, if any }
        public void Execute() { // Select new selection }
        public void Undo() { // Restore previous selection }

The above context may define things like a RectangleSelectionAction, EllipticalSelectionAction, etc.

Stacking them like this allows me to do things like select a section of terrain then go to a different Context to change textures or what have you then return to the selection.

While this is an improvement over putting almost everything in one file it still seems a little strange to me having to define small private classes in each context for each of their major actions.

Is there a standard (or better) way of abstracting out different tools from the main toolkit program to allow for easier development of future tools?

share|improve this question
I like what you describe, but since you are asking for other ways to deal with your situation, I recommend taking a look at Plug-in (Computing). See also: Plug-in Architecture Framework for Beginners, Plugin Architecture, Plug-in Architectures –  Joshua Drake May 7 '12 at 12:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.