VASSAL 4 Object Model

The following is a high-level description of the object model I’ve been pondering for VASSAL 4.

First, a diagram:
[attachment=0]model.png[/attachment]

The object model is divided into three parts: Game Data, Presentation, and Images. Game Data contains the formal properties of the components of a game, Presentation contains the visual/graphical representation of those components, and Images contains the images used in that graphical representation.

The Game Data consists of objects called “pieces”, which are intended to correspond to the (formal properties of) physical bits you find in game. Chits, counters, blocks of wood, cards, maps, etc.—the formal properties of each of these are captured by pieces. A piece consists of two parts: a list of faces, and a set of properties. A property is a key-value pair, where the key names the property and the value is the value that the property has for the piece. Each face in the list of faces has its own set of properties. The properties of a piece are intended to be those which pertain to the piece as a whole, not to some subset of the faces. The properties of a face are intended to pertain solely to that face. For example, “location” or “angle” would in nearly all cases be properties of a piece, not a face, as different faces of a piece cannot reasonably have different locations or angles, while each of a piece’s faces might have a distinct value for “attack strength”.

The Images are simply that: images, to be used for displaying a representation of the game on a screen. Images would be defined as in this thread.

The Presentation joins the purely graphical Images to the purely formal Game Data. The top-level objects in the Presentation I am tentatively calling “visuals”. (I don’t particularly care for this name; please suggest a better one.) A visual is intended to be the graphical representation of a face. One of the properties of a face is which visual represents it (if any), and each visual knows which face it represents. Each visual consists of a list of layers. A layer consists of a set of properties and a reference to an image. Layer properties can be things like “visibility” and “opacity”, indicating how each layer is to be drawn.

I have quite a lot to say about the implementation of each part; however, what I’d like is comments on the concepts, for now, not on the technical details.

Why? For that matter, why are the visuals distinct from other properties of a piece?

Just Curious,
Seth

Thus spake irishwulf:

“uckelman” wrote:

[…] each visual knows which face it represents.

Why? For that matter, why are the visuals distinct from other
properties of a piece?

Just Curious,
Seth

Ah. You made me realize I made a mistake in my description:

A visual will know what face it represents. A face need not know
anything at all about any visual representing it.

Thanks. The connections between the Visuals and the Faces in the
diagram should have an arrowhead on the Face end, indicating that the
connection is only one-way. (Similarly for the connections between the
Visuals and the Images.)

The idea here is that the all of the formal properties of one side of
a physical piece are captured in a Face; all of the (incidental)
graphical properties are captured in the Visual. E.g., the number of
movement points printed on a piece is a formal property and would live
in the Face (or Piece) as one of its properties, while the font that
number is printed in is a graphical property (in all games I’ve seen,
at least), and would live in the Visual associated with that face.

Keeping the formal properties discinct from the graphical ones makes
several things possible and/or convenient:

  • Multiple visuals per Face, in the case that you have multiple views
    of the same pieces (say, a regular view and an overview window).

  • Programs which aren’t displaying graphics don’t need the visuals at
    all. Among such programs might be (1) a game server which maintains
    game stae, (2) AI.


J.

I like the design - the abstraction and encapsulation seem appropriate. This may be an obvious question, but I just want to be sure - all of this design is intended for the platform-independent C++ library, correct?

Thus spake erlloyd:

I like the design - the abstraction and encapsulation seem appropriate.
This may be an obvious question, but I just want to be sure - all of
this design is intended for the platform-independent C++ library,
correct?

Yes.


J.