Chapter 1: Overview of the framework Module
There are nineteen classes and interfaces that make up the framework module, the core of the Macchiato Doppio project. This framework represents the underlying structure of the Macchiato Doppio engine. Here is a brief description of the classes and how they relate to each other:
- GameComp2d: The GameComp2d interface is the underlying interface for all classes in Macchiato Doppio. Modeled after Java3d's SceneGraphObject's "
getUserData()
" and "setUserData(Object)
" methods, the getGameData()
and setGameData(Object)
are used to access the gamedata object. Generally speaking this will be an accounting class, encapsulating all the other objects in the game, allowing easy access to all game data from each class.
- Displayable: The Displayable interface specifies methods that an object has to display itself. Theoretically, objects implementing the Displayable interface will use other classes, such as AnimationForeman, when
display(int,Graphics2D)
is called. setDepth(int)
and getDepth()
are used to set the "depth" of the object, and is used to determine, in relation to other Displayable objects, when it gets drawn (i.e. it allows for the layering of image on the screen).
- Enviroment: The Environment interface is used for things such as levels and backgrounds. It consists of ways to access a 2D array of objects (in the case of tile-based levels these objects will often be Integers).
- Stat: The Stat class is meant to represent a statistic of character or other interactable object in the game (such as a level or weapon). Stats have four
Numbers
associated with them: Minimum, maximum, nominal, and current values.
- Stats: The Stats class is a collection of Stat objects with methods to get and set Stat objects based on name or number, as well as a reset method to reset the values to their nominal value, and a clone method to make a copy of the Stats object.
- Entity: The Entity interface contains methods to get and set Stats, as well as adding and removing Stats. The Entity interface is used as part of the basis for characters and is often added to levels to store information.
- Action2d: Action2d serves a similar function to swing's Action interface, performing an action when the
doAction(Entity,Entity)
method is called. Action2d represents the method for which all, or at least the majority, of game logic is handled. Since Action2d is a GameComp2d extension it has access to all other aspects of the game.
- Condition2d: Condition2d is analogous to Action2d: A class with a single method,
evaluate(Entity,Entity)
, that takes two Entity objects. However, conceptually, they represent two different things, Condition2d evaluates a condition while Action2d performs an action. In the engine module the utility of this is demonstrated in the SimpleCondition class and its methods to get and set Action2d objects that are evaluated when the condition is true. In the framework module they are left seperate for applications where one or the other is desired.
- ConditionPalette2d: The ConditionPalette2d class is a container class for Condition2d objects. It allows easy access to the conditions through the
checkCondition(Object,Entity,Entity)
method, where the Object
represents the name of the condition to be checked. In addition add and remove methods allow conditions added to the palette or removed. This is perhaps the most important class in the framework as it is the place designated for the evaluation of game logic. Through conditions and actions most, if not all, game logic relating the actual mechanics of the game can be performed. The way this is possible may not be immediately apparent but should become clear in the next few chapters.
- Controller: The Controller interface has one and only one purpose: To contain input retrieved and interpreted from listeners until it's polled from the CharacterInteractionModel.
- CharacterInteractionModel: The CharacterInteractionModel is basically the definition of how a character behaves. It brings together two fundamental parts of the framework, a Controller object and a ConditionPalette2d object, and uses them to cause a character to do what it's supposed to. How exactly it accomplishes this is handled in the next chapter, Chaper 2: The Control Loop.
- ImageLoader: Early in the developement of Macchiato Doppio it was determined that a convenient way to load images was needed. The ImageLoader class is a factory class with three methods for loading BufferedImages from the file system designed to provide that convenience.
- Imageboard: The Imageboard class has one and only one function: To contain an image (typically loaded from a file) and when
paintTile(Graphics2D,BufferedImageOp,Point,Point)
is called to paint a section of the image on the Graphics2D context using the BufferedImageOp. Imageboard contains the field tilesize
which tells the Imageboard what size the "tile" (section of an image) needs to be. The first Point
specifies the index of the tile in the image (for example, if an image was 64 pixels by 64 pixels, and the tilesize was 16x16 pixels, and you wanted the section of the image that had a upper-lefthand corner sixteen pixels from the front and sixteen pixels from the top, then your index would be Point(1,1)), while the second Point
tells the Imageboard where on the Graphics2D context you'd like to paint the tile (again, upper-lefthand corner).
- ImagePalette: The ImagePalette class contains a LinkedHashMap of Imageboards. There are a variety of constructors for ImagePalette, and which one should be used depends on how the ImagePalette is going to be asked to display. The constrcutors fall into two different types: Those that ask for names, and those that don't. Those constrcutors that ask for names are most often going to be those used for characters, where AnimationForman will have a key that tells the name of the imageboard each action can be found, and in what order, and will use the
paintTile(Graphics2D,BufferedImageOp,String,Point,Point)
method. Those constructors that don't ask for names are most often going to be those used for levels, where a single coded image file will be used to determine which tiles to use on a pixel-per-tile basis, and will use the paintTile(Graphics2D,BufferedImageOp,int,Point)
method. For a more thorough explanation for how ImagePalette does this see the Javadoc for the class.
- AbstractAnimationForeman: Has two abstract methods for animating an AbstractCharacter2d, and an ImagePalette full of the appropriate images to do the animation. However, since both methods are abstract, only extensions of this class will actually display.
- AbstractCharacter2d: The AbstractCharacter2d class is the base level class for all characters. It contains methods for getting and setting its stats, as well as two methods not specified by Entity for getting and setting the Stats (containter for Stat objects) object. It also has the requesit
getGameData()
and setGameData(Object)
methods specified by the GameComp2d interface. However, the methods for its Displayable interface are unwritten, which means classes that implement this class directly have to write them themselves. Most of the time higher level modules will have taken care of this in their extensions of AbstractCharacter2d, typically by providing a constructor for an extended version of the AbstractAnimationForeman which is then used to display the character.
- AbstractTileForeman: Much like the AbstractAnimationForeman, the AbstractTileForeman is designed so that extensions of it will be able to display tile maps. Three abstract methods are specified: One draws a single tile, one draws a range of tiles, and one draws all the tiles. All of them take as one of their arguments an Environment object, from which the specifics about what tile to draw (and where) are taken.
- AbstractLevel: The AbstractLevel class combines two interfaces, Displayable and Environment, to produce almost everything necessary to have a working level. The final piece is a BufferedImage "map"; the map is a coded image, where each pixel corresponds to a specific tile. The integer representations of each of the color components of the pixel contain the information needed by the AbstracTileForemans methods to draw the correct tile at the given location.
- Procter: The Procter interface is used for defining Procter classes. The Procter class is likely to be the heart of any game made with the Macchiato Doppio framework. The entire purpose of the Procter class is to manage the execution of the game. The way it actually does this is left to the programmer (the actual order in which different opperations in games execute can varry wildly). Methods are specified for beginning, checking and controlling the speed of execution, doing "turns", and checking to see if the game has ended.
The actual relationships between these classes might seem a little strange that the moment. That's to be expected, generally speaking the names, and even the descriptions, of the classes do little to explaing their relation to the whole or the importance that they play. In addition, since the framework is almost entirely abstract classes and interfaces (a necessity for a framework), little can be concretely said about it as a whole. In the next three chapters we will go over the three loops that make up the Macchiato Doppio ideal game loop.
Chaper 2: The Control Loop
Back to front page
Project Page
Forums
email me