Presentation

=Presentation=

System Specification
Graphical Representation


 * The cards will support the following card elements
 * Text, which can be positioned and written in different fonts, styles, colors, rotated, and scaled.
 * Images, which are stored internally in the form of bitmaps, jpegs or other common image formats. These may also be positioned, rotated, scaled and filtered.
 * Shapes which are NOT pre-rendered. They will be drawn in vector format on the card itself and can also be positioned, scaled, rotated, colored and filled.
 * The fill parameter can be a complex expression to produce gradients, transparency, "holograms", and other color-based effects.
 * The cards will be drawn in the following manner
 * The card does not need to be rectangular. Other shapes could be defined by masking out portions of the card which would then be inaccessible.
 * Each element of the card (from the above list) would have a depth associated with it. Elements with the greatest depth would be rendered first and subsequent elements would be rendered on top. This is commonly referred to as the Painter's Algorithm.

External Representation (from user's point-of-view via the scripts)


 * The user will describe the card's creation in its most basic terms. This will be listing the card's generic properties (size and shape) and then each element with its respective attributes. The script will expose customizable elements to the configuration file. The configuration file will use the scripts to set the individual parameters.
 * A user can refer to a subset of a deck by referring to a desired common element, attribute, name, alias, or custom tag defined by the user. This will be done in the configuration file, which distinguishes between groups of cards by setting individual parameters exposed in the script.
 * Referring to an entire deck will be done in the configuration file, the most top-level file the user sees (other than the GUI).

UML

 * Interpreter
 * Builder?
 * Bridge
 * Composite
 * Decorator?

Script Syntax
CARD TAG attributes: name, id

Configuration Syntax
a configuration file (each line has the same format and contains the parameters used to generate a single card) == (equals) a batch file( each line has the same format and contains the parameters which are passed to the script to generate a single card to create an entire deck.

0-4 treeCard.card parameter1, parameter2, parameter3 5 waterCard.card parameterRandom 6-10 brickCard.card

Script Example
code format="javascript" Script RFG background = template for each element decorate element.name positionx, positiony code

code TemplateScript.script variables: $type ["fta" || "gf"]

canvas = createPolygon(0px, 0px, 500px,300px); canvas.paint(Color.Black); canvas.roundEdges(10px); bg = createImage($type+"_bg.png", relative to canvas, .25in, .25in);

code

Configuration Example
in the config file Card example = new RFG(RFGTemplate, Image(location, x, y), DescBox(contents, x2, y2), DiceBox(2,1,x3,y3))

Discussion Areas
Decorator Allows an advanced user of the system to extend functionality. The Decorator can then be hooked into the template method inside the interpreter.

Script

 * Pros
 * more control to the scripter
 * Cons
 * becomes harder to follow / messier script

Builder

 * Pros
 * less control to the scripter and more control to implementer / programmer
 * more solid design
 * cleaner scripts / easier follow
 * Cons
 * use of more variable / less control over variations and customization