MAE Data Types
The HashArray data type is a key-value container.
It is typeless, but a specific type can be asserted (e.g. setBool()) or retrieved (e.g. getBool(), getInt(), etc). It is up the the application to store/retrieve by type consistently.
This data type is very convenient for messaging. Calling the toString() method converts the HashArray into a string. Using the fromString() method or constructor converts it back.
What makes this XML class special is that the XML is generated from records, so it
follows a readily parsable pattern when read back in.
<recordtype id="n" pname="paramname" >
<propname >propvalue </propname >
... additional properties
<subnodename >
<recordtype id="n" >
...
</recordtype >
</subnodename >
... additional subnodes
</recordtype >
Properties a simple values inside a record. Subnodes are sub-records inside a record.
*
Note that when writing out XML property values, substitutions happen for <, >, &, " and '.
This class uses the HashArray class for key-value properties.
This is a simple graph class for general application.
Each node has a label, adjacency list, visited flag, and app-specific data.
The UserDevice class is used to identify an I/O endpoint abstractly so an application can have a handle to that endpoint without needing to understand protocols, terminal information, graphics standards, etc. This class abstracts all of that.
An I/O endpoint is a user. The user operatates in a role, presently the roles are dm (referee) and pc (player). A pc is unique to a setting or game milieux/environment/system. A dm may referee multiple settings. A pc connection may be from the owning user id, a proxy user id (friend), or the dm.
An I/O endpoint runs one or more applications inside the system. This is called the app mode.
The UserDevice class captures the role, user id, pc id, setting id, and app mode. Those elements uniquely identify a endpoint/connection.
The endpoint has predefined elements: menus, attention box, and chat box. The menus are implmented using the local graphics system. Menus are only two-levels. An attention box is a prominent way to present a message/alert to the user. The chat box is used for communicating among multiple users.
The UserDevice class also has an optional pararameter known as a region. This is an area/hotspot/named element of the interface. To format text into something attractive, the various elements of the screen/page/display are named. Text is sent to that named region so output appears comprehensible (and hopefully user-friendly!) to the end-user. When the user enters data, clicks or otherwise activates an element of the interface, that element's name is passed through UserDevice as the region.
The UserDevice class has a method toString() which can be later passed to instantiate another UserDevice with all the key information.
Syntax:
This string follows the format:
role:/userid/pcid/wid/app[/region[/group]
where
Term |
Description |
role |
The role is either dm or pc. In DM role, the userid must be non-zero; and the pcid is 0. |
userid |
The id from the User datastore. In PC role, the userid may be 0 to broadcast something to all endpoints in used by the pc. In PC role, pcid must be non-zero. |
pcid |
The id from the PC datastore. In DM mode, the pcid is 0 for privileged/referee interaction. |
wid |
The id from the Setting datastore. |
appmode |
The appmode can be one of: console, userman, mapedit, hexit, market, supervisor. The label for the appmode may be 100 characters or less. |
region |
The region varies based upon the appmode. It identifies the UI area of focus, whether for input or output. The region 'attn' is common to all apps; it represents the attention box. The label for the region may be 100 characters or less. |
group |
This is an internal value used for routing. |
Example UserDevice endpoint identification strings:
dm:/1/0/console
pc:/1/3/console
pc:/3/3/3/console//E3
pc:/3/3/3/console/attn/E3
pc:/3/3/console/attn
UserDevice is implmented using messages across a message bus to two daemons: usergw (channel: display) and guibroker (channel: input, gui). The usergw daemon is like a device driver - it knows how to convert the request into the graphical display's protocol/API/syntax. It also knows how to take input from the endpoint and standardize it into an understandable input in this system. It forwards those inputs to the guibroker daemon. The guibroker daemon plays two key roles: it responds to user input (such as user keystroke, mouse click, hotspot activiaction or command request) and it handles non-simple I/O (such as prompting user with a question, sending a user interface control (selector, textbox), or handling a form with multiple input entry areas). The guibroker daemon is more abstract than the device-aware usergw daemon.
Input initiated by the user and non-simple I/O is then translated into requests on the message bus to which system applications subscribe and process. For example, the setting daemon as a SettingApp class with a method to process messages on the 'setting' channel. These messages often come from guibroker, but they may come from other daemons in the system as well. The SettingApp daemon acts as a setting processor that responds to its defined set of requests.
This data structure abstracts a vector image. The API is used to describe the image. It is not rendered into JPG, PNG, SVG, or other specific image technology until it is ready to be rendered to the end-user. Rendering is performed by the imager daemon.
The API could be richer, but the API must be able to render to each of the ultimate image types.
The Image class may refer to an existing image file in a specific format via ImageLib class, which specifies where to retrieve the image and the image's size.
setSize(double newWidth, double newHeight, int newUnitSize)
Set the canvas dimensions and specify how many pixes per unit. For example, a 4.0x5.0 image where unit size is 10 would create a 40x50 pixel image.
setOrigin(double newOriginX, double newOriginY)
Specify how many units over the origin should be located if (0,0) is the lower left
setWindow(double minX, double minY, double maxX, double maxY, int newUnitSize)
Specify the width and origin implicitly by specifying the window into the view. Use this instead of setSize() setOrigin()
drawBox([[#Point]] corner1, Point corner2, string color, bool fill, string link)
Draw a rectangle with the corners specified. Default color is black. The box may be an outline or solid/fiilled.
An optional link (e.g. URL) may be provided if resulting image supports linking.
drawLine([[#Point]] p1, Point p2, string color, string link)
Draw a line from p1 to p2 of the color specified.
An optional link (e.g. URL) may be provided if resulting image supports linking.
drawCircle([[#Point]] center, double radius, string color, bool fill, string link)
Draw a full circle with the specified center and radius. The default color is black. The circle may be an outline or solid/fiilled.
An optional link (e.g. URL) may be provided if resulting image supports linking.
drawText([[#Point]] start, string text, string color, string link)
Draw text into the image with the lower left corner of the text at the start point.
bool drawArc([[#Point]] center, double startang, double endang, double radius, string color, bool fill)
drawPolygon([[#Point]]List p, string color, bool fill, string link)
Given a series of points, draw the enclosed polygon. The default color is black. The polygon may be an outline or solid/fiilled.
An optional link (e.g. URL) may be provided if resulting image supports linking.
drawPolyline([[#Point]]List p, string color, string link)
Given a series of points, the the line that connects them from start to end. The default color is black.
An optional link (e.g. URL) may be provided if resulting image supports linking.
This class holds a reference to and then ultimately delivers the binary content of an image in the Image Library (the ImageLib table). This class holds the image id, name, category, image type, height and width of the image.
The IniFile class is used to read .ini files and provide methods to query values from its various sections.
The IniFile class reads a standard INI file format.
Syntax:
The first line of output is the headers:
AppName,Section,Variable,Value
where,
Header |
Description |
AppName |
The name of the application for these properties. |
Section |
The section (grouping) of the application for these properties. |
Variable |
The keyword for the property. |
Value |
The value of the property. |
A document is a abstract document that is not format specific until it is rendered.
Today, a document can be output to HTML or PDF. Other formats are expected for the future.
A document is made up of a series of blocks.
An example block is: header, paragraph, table cell, image
A block is made up of a series of items.
An example item is: text fragment of a particular style.
White space is not automatically added between items.
A region is a block.
Text written to a region is appended.
A bookmark is an anchor where a link from elsewhere in the document points to.
A link points to a bookmark inside the document. An external link points to somewhere outside the document.
An index key is the text that appears in a generated index, perhaps different from the text it references.
When headers are used, Document can generate a table of contents for the document.
When named indexes are used, Document can generate an index for each named index.
Dice play central roll in this game. When rolled by the computer, they must be specified in an understandable format.
Dice follow this general format:
[qty]dsides[+offset][xmultiplier]
where
Term |
Description |
qty |
Optional. An integer that specifies the number of dice to roll. |
sides |
The number of sides on the dice. |
offset |
Optional. How much to add to the result of the dice roll. |
multiplier |
Optional. How much to multiply the dice roll by. Multiplication is applied last, even after offset. |
+4
-4, 4
%d, %d+5
d4, 1d4, 2d4, 2d4+3, d20+4
d4x10, 1d4x10, 2d4x10, 2d4x10+3, d20+4
d0+5