Some of this documentation currently is for the ActionScript 2 version of Bloxley. It's in the process of being changed.
Classes marked with a * are significant to understanding the framework as a whole.
A container for the root superclass, and included libraries.
The superclass for all higher-functioning bloxley classes. It contains code for reflection, method cascading, and to interact with the notification and semaphore systems.
An included library for generating and parsing JSON.
This contains all of the main event logic code.
An atomic game action, ie, game state change. All game actions are subclasses of this class.
A change in a color attribute of an actor.
An addition of a new actor to the board.
This is a superclass for an action which involves actors moving around the board. This action is designed to cause other actions.
A large-scale change of the patches on a board.
A board change that specifically involves the board becoming smaller. Used by a standard interface component.
The removal of an actor from the board, especially in edit mode.
Makes an actor disabled--not able to be selected, but not destroyed.
An event is a group of actions, organized causally. They are undone as a group.
A board change that specifically involves adding a row or column to the board.
The most common game action an actor moves some number of steps in a direction.
A change in a color attribute of a patch.
A board change that specifically involves setting all of the patches to a new type.
Changing a single patch to a new type.
Placing an actor at some fixed place on the board. Not for gameplay purposes (use BXMoveAction).
Changes the currently selected actor.
A move action that repeats until it fails.
This is an undo queue--it keeps track of events, and undoes them in a LIFO order.
These classes are the main game controller-layer classes.
The superclass for actor behavior. Each type of actor should have an individual BXActorController subclass.
The superclass for game behavior. Each game should have a subclass of BXController.
The superclass for patch behavior. Each game should have at least one BXPatchController subclass.
The mailbox is a universal implementation of the Observer Pattern. Modeled after Cocoa's NSNotificationCenter, objects can be registered to be notified in three different circumstances (1) A specific object O sends a specific message M (2) A specific object O sends any message (3) Any object sends a specific message M Note that the sending object does not needs to know about the existence of the listening object.
A request to call some method, on some object, later in the current frame.
Manages delayed calls, calling each in turn.
The implementation of the Observer Pattern. Any object can be set to be notified when a message that it cares about is generated.
An object is listening to a/any message from a/any source.
A group of observers, all observing the same object/lack of object.
The pen is how the user interacts with the game. It handles mouse events, keyboard events (treating arrow keys specially), and drag-and-drop.
A pen to change some attribute of patches that are clicked on.
A pen to change a color attribute (defaults to 'color') of patches or actors that are clicked on.
An object representing something being dragged.
A simple gameplay pen--pressing an arrow key moves the currently selected actor in that direction, and pressing space switches the selected actor. Can be used as a subclass for more complex game pens.
Represents what the user is doing with the mouse--pressing it, releasing it, or dragging it.
A pen for dragging objects around.
A pen for changing the type of patches.
The superclass for pens. Doesn't contain much logic itself, but includes hook methods for all of the events that it the framework handles.
A pen for selecting a rectangular region of the board.
Phases are the implementation of game flow.
A phase is an atomic unit of game flow. Phases can be entered, exited, and either succeed or fail.
It performs the main game loop, and handles the transitions between phases.
Handles loading a game interface from a server.
Handles loading a game level from a server.
A superclass for communication with a server. Has methods to implement indicating success or failure.
The actual communication request to a server. It keeps track of the progress, and returns to the loader the data upon success or failure.
A mapping between a character and a patch key. Used in the XML representation of levels.
A collection of tiles--handles mapping between patch keys and characters.
Defines smarter collection classes than the base ActionScript Array class. Defines the common functional meta-methods (select, map, etc.)
A set, specifically of actors.
An ordered sequence of patches. Can be walked.
A set, specifically of patches.
The superclass of collection objects. Can be iterated over.
Small data objects.
A color.
A direction on a board (North is up).
The major model objects for the bloxley framework.
An object on the board that can move around, and be any size.
A grid of patches, which actors can sit upon.
A single "square" of a board. It can change attributes, but it cannot move or change size.
An animation is any visual change over time.
A change in 2 related attributes simultaneously, like x & y or width & height.
An animation is something with a start and finish, that gets updated every frame to cause visual changes.
A blend is a change of some attribute over a period of time.
A choreographer walks an event tree, and determines from the causal relationships how each events' animations are to be sequenced in time.
A change in a circular attribute, like angle of rotation.
A no-op placeholer animation.
A sample compound animation of a patch fading from one frame into another.
An animation that is a sequence of frame changes.
An instantaneous animation that involves all patches being visually updated at once.
An animation that allows several animations to be treated as a single one.
The game clock keeps track of the frame, and elapsed time during the game.
The clock handles all time and frame related tracking. It sends signals at the start of every frame.
A signal is a request to send a signal after some time has elapsed.
Manages signals, and determines if & when a signal should be sent.
A timer sends a signal every frame, and every second, until some set time is reached.
These are gui elements (buttons, labels, images, drag wells, etc.)
A single button that can be clicked on, and sends a message when it gets hit.
A group of buttons, displayed visually as a unit.
The geometry is the grid square size for a BXGrid.
The visual display of a BXBoard.
The superclass of all interface elements.
A bitmap image.
A text label. It can be given different display formats depending on what it displays plain text, money, score, or time.
A vector art image. Will be folded into BXImage.
A rectangle used to display the current selection on a board.
A two-setting toggle switch, similar to the iPhone display.
A drag-and-drop well, usable as a drag source or drag target.
Sprites are the superclass of everything that gets displayed on the screen.
A sprite made up of layers of sprites. Can be nested. Moving, resizing, etc, the composite sprite will update all of the sprites within.
A visual object which can be displayed, moved, resized, etc.
Keeps track of changes to a sprite, so that it only gets updated once per frame.