Recommend
11 
 Thumb up
 Hide
255 Posts
1 , 2 , 3 , 4 , 5  Next »  [11] | 

BGG» Forums » Gaming Related » Computer Based Board Gaming

Subject: A standard format for representing game components rss

Your Tags: Add tags
Popular Tags: [View All]
Joel Uckelman
United Kingdom
Durham
flag msg tools
Microbadge: Vassal playerMicrobadge: GrognardMicrobadge: Open Source programmerMicrobadge: Linux userMicrobadge: Beer fan
On this thread, a discussion started about devising a common format to be used by programs for representing game components. Here I present a sketch of such a format.

Goals:

* provide a mapping from game components to the images representing them
* provide a way of representing semantic information about game components
* provide an extensible format for program-specific data

Plan:

My plan for meeting these goals is an XML-based format, because there are abundant tools for editing and manipulating XML, as well as libraries for reading and writing XML and marshalling objects from XML in every widely-used programming language. XML is syntactically very simple and self-representing, so will tend to be more human-readable (so long as we make good design choices) than formats like JSON and YAML; it's also more likely that potential users will already be familiar with XML syntax (due to the by now long-standing use of HTML on the web) than for other formats.

Design:

What I'm proposing here is not a specification; rather, it's an example that suggests a particular specification. I want to give concrete examples for people to comment on, rather than a DTD at this stage.

We need a way of specifying the locations of images we'll be using, as well as a way of referring to those images. We can define an element which provides both:

<img id="1" src="counters.png" />
<img id="2" src="counters_mask.png" />
<img id="3" src="XXX_corps_front.png" />
<img id="3" src="XXX_corps_back.png" />
<img id="4" src="map.png" />
<img id="5" src="crt.png" />
<img id="6" src="turntrack.png" />

The id attribute is a unique identifier. The src attribute is a URL, which could point to somewhere inside a module archive file, somewhere on the user's filesystem, somewhere on the web, etc.

Next, we need a way of defining game pieces and tying images to the game pieces they represent. Game pieces have one or more faces. (A cardboard chit will have one or two, a three-dimensional thing that has only one orientation such as a pawn will have one, more complex objects might have more.) A single image might contain the faces of several game pieces (ZunTzu handles images for whole counter sheets this way), or might contain the image for only a single face:

<piece id="7">
<face id="8" img="3" />
<face id="9" img="4" />
</piece>

Here, we've assigned a unique identifier to this piece. It has two faces, formed by the entire contents of images 3 and 4, respectively. If we want a face to be a cutout from some larger image, we can specify the bounds of the cutout:

<piece id="10">
<face id="11" img="1" x0="100" y0="100" x1="150" y1="150" />
<face id="12" img="1" x0="150" y0="100" x1="200" y1="150" />
</piece>

We could also support masks for non-rectangular pieces:

<piece id="13">
<face id="14" img="1" mask="2" x0="100" y0="100" x1="150" y1="150" />
<face id="15" img="1" mask="2" x0="150" y0="100" x1="200" y1="150" />
</piece>

(Note: I'm unsure whether it's necessary to support masks, as the masking could be done in an image editor.)

This covers every way of specifying subimages I've thought of. If there are more useful ways, I'd like to know what they are.

Similarly, images are associated with maps and charts. One additional wrinkle here is that we might like to place two maps adjacent to each other, or arrange some charts in a particular way. For this, we define a element, which you can think of as corresponding to a tabletop:

<surface id="16" name="Map">
<map id="17" img="4" x0="0" y0="0" />
</surface>

<surface id="18" name="Charts">
<map id="19" img="5" x0="0" y0="0" />
<map id="20" img="6" x0="500" y0="0" />
</surface>

Here, we define and name two surfaces, the first one containing a game map, and the second containing two charts. Positions on the surface are given by the x0 and y0 attributes. The map with id 20 is to the right of the map with id 19 on the Charts surface.

Finally, we introdue a element for dice:

<!-- a red d6 with white pips -->
<die id="21" sides="6" color="FF0000" pips="FFFFFF" />

The color and pips attributes are RGB values in hex notation. There might be some need to associate images with die faces to handle special dice which come with some games:

<die id="22">
<face id="23" img="1" x0="200" y0="100" x1="250" y1="150" />
<face id="24" img="1" x0="250" y0="100" x1="300" y1="150" />
<face id="25" img="1" x0="300" y0="100" x1="350" y1="150" />
<face id="26" img="1" x0="200" y0="100" x1="250" y1="150" />
<face id="27" img="1" x0="250" y0="100" x1="300" y1="150" />
<face id="28" img="1" x0="300" y0="100" x1="350" y1="150" />
</die>

This would represent a d6 that has three pairs of matching faces.

Questions:

* Is this adequate? Can anyone think of game components that would be difficult or inconvenient to represent this way? (There's nothing I've thought of in any game I own or have seen which this wouldn't work for.)

* Are things well-named? (I'm not necessarily happy with using the name "map" for elements which also represent charts, but I've not thought of a word which suggests both, and it seems needless to have an otherwise identical element called "chart".)

* Would it be better to have the image cutouts as be their own element, so that piece faces could refer directy to the cutouts by id instead of repeating the cutout dimensions? E.g.:

<img id="1" src="counters.png" />
<img id="2" subimg="1" x0="50" y0="50" x1="100" y1="100" />
<img id="3" subimg="1" x0="100" y0="50" x1="150" y1="100" />

<piece id="4">
<face id="5" img="2" />
<face id="6" img="3" />
</piece>

This is more concise than what I proposed above if one subimage is used repeately, and means that image faces don't need to concern themselves with whether their images are cutouts.

* Would it be better to specify bounds as (x,y,w,h) instead of (or in addition to) (x0,y1,x1,y1)?

* It might be nice (labor-saving) to be able to specify image cutout sections of uniform width and height as a grid. Something like this:

<img id="1" src="counters.png">
<igrid id="2" x0="0" y0="0" x1="300" y1="500" rows="10" columns="6" />
<!-- skip the gutter between two sections of pieces -->
<igrid id="3" x0="0" y0="520" x1="300" y1="820" rows="10" columns="6" />
</img>

Then we would need a way to refer to grid locations:

<piece id="4">
<face id="5" img="1" igrid="2" row="2" column="5" />
</piece>


* I haven't said anything about how to represent semantic information here. I'm mostly out of time for today, so I'll return to that tomorrow.

Thoughts?
7 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Hi Joel,

I'm interested in your goal here, and would like to provide feedback if possible... I'm assuming your example xml was stripped by the forum code?

 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Justin
United States
Creve Coeur
MO
flag msg tools
badge
Avatar
Microbadge: AnarchistMicrobadge: AtheistMicrobadge: I keep my ratings currentMicrobadge: Parent of Two GirlsMicrobadge: St. Louis Cardinals fan
Quote:
...XML...will tend to be more human-readable...than formats like...YAML...
You already lost me.
10 
 Thumb up
0.05
 tip
 Hide
  • [+] Dice rolls
Justin, having a bit of a love/hate relationship with xml myself my instinct would be to agree that yaml/json is generally more readable (especially for those that don't breathe code), but I'd like to see Joel's xml examples first.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Joel Uckelman
United Kingdom
Durham
flag msg tools
Microbadge: Vassal playerMicrobadge: GrognardMicrobadge: Open Source programmerMicrobadge: Linux userMicrobadge: Beer fan
R0B0T0 wrote:
Hi Joel,

I'm interested in your goal here, and would like to provide feedback if possible... I'm assuming your example xml was stripped by the forum code?

Oh good lord. The example xml showed up just fine when I hit preview. This is one of the reasons why I hate using web fora for things like this instead of mailing lists... ARGH!

Edit: There, the XML shows up now, not just in preview mode.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Good thing!
Something like that is missing and BGG is probably the right place to start it.
What you need in the end is a specification though. And please don't mention DTD: I hope you meant an XSD.

XML is the right way to go. JSON is just an encoding, it is semantically too weak.

I think that you can collect requirements in one thread here. What needs to be represented? Then a small group of 3-5 can hammer out the details (preferably someone who's familiar with these kind of specs).

At least my goal would be to have a format which lasts the next 20 years and this can probably be achieved here.

Don't put too much weight on human readable. If you try to do real things neither XML or JSON are very human readable when the files grow big enough. That's what editors are for and there are so many developers here, that I'm sure that someone will provide an editor.

Go ahead, looking forward to the results!

/Sparhawk
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
uckelman wrote:
R0B0T0 wrote:
Hi Joel,

I'm interested in your goal here, and would like to provide feedback if possible... I'm assuming your example xml was stripped by the forum code?

Oh good lord. The example xml showed up just fine when I hit preview. This is one of the reasons why I hate using web fora for things like this instead of mailing lists...

I'm not sure that I have time to recreate it all this evening.
Select requirements here and do the real work in a wiki.
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Dave Nellis
United States
Denver
Colorado
flag msg tools
badge
Avatar
Microbadge: Plays Games At LunchMicrobadge: Unix programmerMicrobadge: Scotch drinkerMicrobadge: Civilization Computer Game fanMicrobadge: I was here for BGG's Tenth Anniversary!
Idea:

Why provide the cut-out functionality as part of the format? I assume that its provided to make it easier for developers to scan in entire sheets, but why not just provide a tool that can allow developers to easily convert scanned counter sheets into the more 'normalized' format? This has the advantage of making the standard format simpler as you're only representing things a single way. This could make the standard format more likely to be accepted. You'd have to advertise that that counter sheets were supported via the tool to avoid grumbling.

Did I just volunteer to create this thing?
3 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Shatner wrote:
Idea:

Why provide the cut-out functionality as part of the format? I assume that its provided to make it easier for developers to scan in entire sheets, but why not just provide a tool that can allow developers to easily convert scanned counter sheets into the more 'normalized' format? This has the advantage of making the standard format simpler as you're only representing things a single way. This could make the standard format more likely to be accepted. You'd have to advertise that that counter sheets were supported via the tool to avoid grumbling.

Did I just volunteer to create this thing?
I didn't understand at all what you are proposing. Sorry. If I have a box full of wooden parts and want a format to store the contents in an .xml file, what exactly would I scan?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Dave Nellis
United States
Denver
Colorado
flag msg tools
badge
Avatar
Microbadge: Plays Games At LunchMicrobadge: Unix programmerMicrobadge: Scotch drinkerMicrobadge: Civilization Computer Game fanMicrobadge: I was here for BGG's Tenth Anniversary!
Sparhawk wrote:
Shatner wrote:
Idea:

Why provide the cut-out functionality as part of the format? I assume that its provided to make it easier for developers to scan in entire sheets, but why not just provide a tool that can allow developers to easily convert scanned counter sheets into the more 'normalized' format? This has the advantage of making the standard format simpler as you're only representing things a single way. This could make the standard format more likely to be accepted. You'd have to advertise that that counter sheets were supported via the tool to avoid grumbling.

Did I just volunteer to create this thing?
I didn't understand at all what you are proposing. Sorry. If I have a box full of wooden parts and want a format to store the contents in an .xml file, what exactly would I scan?
I think Joel is proposing support entire sheets of counters, in addition to supporting individual ones. Supporting entire sheets would include providing coordinates so a system reading the standard format could cut the large image into smaller ones. I'm claiming that this needlessly complicates things by having two different ways of representing the same thing, and that cutting images into smaller ones should be handled by a tool, and not the data format.

This could also apply to things like cards I imagine as a developer would want to scan in an entire bed of cards rather than scan each card individually. This wouldn't help at all with the 3D pieces you mention. :) That's an entire different problem. I'm guessing whatever is being proposed will be robust enough that a Meeple or some such thing could be represented by anything from an image to a 3D Mesh that some one built.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Indeed, now that I can see the example XML, I can also see the coordinates and where that is going.

I see that it will be a challenge to find the right set of requirements. So, you are scanning the cards. Perhaps there is text on the card. So probably you want to have the text also in a string. And then there are variants and different languages. And perhaps there isn't only one piece of text but several.
And perhaps there is also a way to capture a bit of semantics about the card. Is it a money card or action or unit or ...?

So, there's quite a bit of potential to push it too far.

Interesting stuff.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Joel Uckelman
United Kingdom
Durham
flag msg tools
Microbadge: Vassal playerMicrobadge: GrognardMicrobadge: Open Source programmerMicrobadge: Linux userMicrobadge: Beer fan
Shatner wrote:
Idea:

Why provide the cut-out functionality as part of the format? I assume that its provided to make it easier for developers to scan in entire sheets,
That's one reason. Another is that it can be much more efficient, for storage, editing, and within a program's graphics subsystem to store many small images in one larger image. A third would be if you have cutouts which overlap.

Quote:
but why not just provide a tool that can allow developers to easily convert scanned counter sheets into the more 'normalized' format?
It wouldn't be hard to script up something like that in ImageMagick, for example.

Quote:
This has the advantage of making the standard format simpler as you're only representing things a single way.
I don't see that it adds much complexity, when you consider that single-cutout images are a special case (x0="0" y0="0" row="0" column="0") of images containing multiple cutouts.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Joel Uckelman
United Kingdom
Durham
flag msg tools
Microbadge: Vassal playerMicrobadge: GrognardMicrobadge: Open Source programmerMicrobadge: Linux userMicrobadge: Beer fan
Sparhawk wrote:
I see that it will be a challenge to find the right set of requirements. So, you are scanning the cards. Perhaps there is text on the card. So probably you want to have the text also in a string. And then there are variants and different languages. And perhaps there isn't only one piece of text but several.
I want to be image-format agnostic, so we can support scans and bitmaps generally, but also things like SVG. Personally, if I had cards with text (or actually, almost anything, because game art is usually line art) I would use SVG.

I do see your point about languages. It might be useful to be able to specify a language code.

Quote:
And perhaps there is also a way to capture a bit of semantics about the card. Is it a money card or action or unit or ...?
Yes, I intend to write up an example of that tomorrow. What I posted above is on the minimal end---just what's needed for a virtual tabletop program to display the game components. The maximal end of the spectrum would be to represent all rules-relevant properties or the game components as data.
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Heath Doerr
United States
Farmington Hills
Michigan
flag msg tools
Origins 2020 Jun 17th - 21st
badge
Unplayed Countdown: 9 left to play
Avatar
Microbadge: I play with blue!Microbadge: I like to play NEW gamesMicrobadge: Origins attendeeMicrobadge: I have at least 2,000 logged game plays!Microbadge: Golden Image Uploader
Shatner wrote:

cutting images into smaller ones should be handled by a tool, and not the data format.
I disagree. Precision is paramount when working with counters, because the images need to align exactly to make stacks work. If you stack images of counters that are irregularly sized, you may be able to tell where a certain piece is in the stack, which could compromise the game if randomness is important.

That's why a GUI is the wrong place for this data to be created. Scanning an entire counter-sheet and manually defining edges will never be this accurate.

The proper way to do this is to develop a mask in your image editing tool which is aligned correctly, and then nudge your scans to fit the template. The XML is easy to create if you've done it this way, because you know that every piece is exactly the same size as the pieces that surround it. I can provide more information on how this is done, but I can say that even if a tool existed, I wouldn't use it.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Heath Doerr
United States
Farmington Hills
Michigan
flag msg tools
Origins 2020 Jun 17th - 21st
badge
Unplayed Countdown: 9 left to play
Avatar
Microbadge: I play with blue!Microbadge: I like to play NEW gamesMicrobadge: Origins attendeeMicrobadge: I have at least 2,000 logged game plays!Microbadge: Golden Image Uploader
This is a great start! Here are a few additional ideas to consider:

Dials

Games like Thebes, El Grande, Civilization and Dune have discs which need to be spun to reveal values. I propose a specific counter format which defines an image that rotates at a specific angle on top on another image, at X degrees per rotation. When the piece is rotated, it will remain on top of the image below it, and rotate at the variable degree interval.

3D Objects / Rotation in another Axis

Rotating a 2D object is fairly straight forward, but it is entirely different to rotate a 3D game object on a virtual table top. Rotating a Zombie figure (for example) usually means that after 180 degrees of rotation, the figure looks upside down (standing on its head) instead of facing the other way. That's why it would be better to define a series of images, taken at different angles, that could be scrolled through when a 3D object is rotated. Instead of the same image being manipulated, you would be flipping forward and backwards from images X to X+1 or X-1, with an eventual loop back to X. The effect would be user defined with the number of angles (e.g. using compass directions: N, E, S, W)

Yahtzee Style Dice Management

In addition to defining dice color and number of faces, I would also like to see legal dice throws, and locking and unlocking of dice defined in the specs. For example, an element that defined a dice hand as consisting of up to 6 dice, with locking available, and locks only work for 3 throws before they reset.

Stacking Behavior

It would be nice if you could enforce stacking relationships between counters. For example, in Tikal, large counters have the ability to be stacked with medium counters, which can be stacked with smaller counters. It is never desirable to have a large on top of a small, or any other combination. Similarly, in Axis & Allies the figures always go on top of the chips, never the other way around.

Randomness Generators

Many games use bags, or other methods where a piece is removed from a set at random. There should be a mechanism for defining sets which allow random removal of piece(s), and optionally replacing the counters removed back into the set.

Two Sided Pieces with Hidden Values

Stratego and Hammer of the Scots use pieces which have sides which are only visible to one player. There should be a way to define who can see the front or the back of a piece.

Counter Values

Values for counters that represent money, or other units that can be totaled should be part of the design. That way the game tool can provide the user summary statistics at a glance. This should also be defined as public or private knowledge.

1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David Kershaw
Ireland
Belfast
Northern Ireland
flag msg tools
designer
publisher
WARGAME!
badge
Lines of Battle: Quatre Bras 1815. Brunswick hussar.
Avatar
Microbadge: Miniatures wargaming fan - NapoleonicMicrobadge: I've played games in Northern IrelandMicrobadge: Autism AwarenessMicrobadge: I love running!Microbadge: Wargame Design Hobbyist
I thought that the xml tool would be used to describe the individual counters themselves... not how to cut them out... never mind games with non-regular counters or counters pre-punched.

How is the map to be described in xml? Is the proposal to simply scan it as well, or to use xml to describe each hex/area and it's relation to it's connected neighbours, along with terrain.

Something (pseudo code) like this, for a square in a chessboard:

-area-
-name-black square 1-/name-
-terrain-black-/terrain-
-connection-
-name-white square 1-/name-
-terrain-straight connection-/terrain-
-/connection-
-connection-
-name-white square 5-/name-
-terrain-straight connection-/terrain-
-/connection-
-connection-
-name-black square 5-/name-
-terrain-diagonal connection-/terrain-
-/connection-
-/area-
-area-
-name-white square 1-/name-
etc...


Being extensible, various tags could be optional or not. So you could define each area's spatial arrangement, if needed.

*EDIT* what a pain not being able to enter chevrons
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Peter B
United States
Pittsburgh
Pennsylvania
flag msg tools
Avatar
Microbadge: 6502 Assembler-Dawn of microcomputingMicrobadge: Quarter to Three fanMicrobadge: Apple userMicrobadge: I listed a Boardgame at the GfG LotteriesMicrobadge: Ancients Wargamer
Initial comments:

I agree with Sparhawk that you probably want to start by thinking about requirements than working backwards from a suggested implementation. Off the top of my head, here are some of the issues that your proposed implementation (or suggestion of an implementation...) may make harder.

(1) Resolution independence. Encoding absolute pixel values is going to make sizing for different screen sizes (or orientations) difficult.
(2) What color space are these RGB values in?
(3) Should probably be thinking about i18n sooner rather than later.
(4) I think the "bounds of a cutout" think is a great example of something that sounds like a convenience for module developers but which will turn into a nightmare if it's actually part of the file format. Specifically, it mixes what should be a semantic concept ("This is the TurboLaser piece. It has this image, two sides, facing is not important, and it is part of the Weapons stack. It starts the game in a random Pandora pod, face down.") with a detail that is absolutely unimportant once the module is in production ("The image on this piece is at coordinates x,y on sheet 2"). This is exactly the sort of thing that should be handled by the tool that generates the output rather than encoding the details in the format itself. IMHO.

Sparhawk wrote:
If you try to do real things neither XML or JSON are very human readable when the files grow big enough.
QFMFT
3 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Joel Uckelman
United Kingdom
Durham
flag msg tools
Microbadge: Vassal playerMicrobadge: GrognardMicrobadge: Open Source programmerMicrobadge: Linux userMicrobadge: Beer fan
peterb12 wrote:
Initial comments:

I agree with Sparhawk that you probably want to start by thinking about requirements than working backwards from a suggested implementation. Off the top of my head, here are some of the issues that your proposed implementation (or suggestion of an implementation...) may make harder.

(1) Resolution independence. Encoding absolute pixel values is going to make sizing for different screen sizes (or orientations) difficult.
1. If my experience with VASSAL is any indication, some (most?) of the images will be bitmaps. Bitmaps aren't resolution-independent. How do you do cutouts from bitmaps in a resolution-independent way?

Would specifying units (as in SVG) be a solution?

2. I don't understand what you mean about orientations.

Quote:
(2) What color space are these RGB values in?
sRGB. I suppose we could add an attribute for specifying the colorspace.

Quote:
(3) Should probably be thinking about i18n sooner rather than later.
How would you do it?

Quote:

Sparhawk wrote:
If you try to do real things neither XML or JSON are very human readable when the files grow big enough.
QFMFT
I don't understand this claim. Reading is local, the size of the file is global. How can the size of the file make it hard to read parts of it?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Joel Uckelman
United Kingdom
Durham
flag msg tools
Microbadge: Vassal playerMicrobadge: GrognardMicrobadge: Open Source programmerMicrobadge: Linux userMicrobadge: Beer fan
kerpob2 wrote:
I thought that the xml tool would be used to describe the individual counters themselves... not how to cut them out... never mind games with non-regular counters or counters pre-punched.
* Describing a mapping from components to images is the bare minimum that I want from this format.

* Counters which are nonrectangular are ultimately rectangular anyway (with some transparent areas), since the images which represent them will necessarily have rectangular bounding boxes.

* The method of specifying cutouts is there because images might be coming from countersheeet scans; if not, it can still be convenient for designers to work from a single image file containing all piece images. Nothing requires you to work that way, however; single-image files can be specified just as easily.

Quote:
How is the map to be described in xml? Is the proposal to simply scan it as well, or to use xml to describe each hex/area and it's relation to it's connected neighbours, along with terrain.
This falls under my above comment---no semantic information is needed just to provide a way of displaying the game components. Experience has shown me that some maps will be scans, some will not be.

Quote:

Something (pseudo code) like this, for a square in a chessboard:

-area-
-name-black square 1-/name-
-terrain-black-/terrain-
-connection-
-name-white square 1-/name-
-terrain-straight connection-/terrain-
-/connection-
-connection-
-name-white square 5-/name-
-terrain-straight connection-/terrain-
-/connection-
-connection-
-name-black square 5-/name-
-terrain-diagonal connection-/terrain-
-/connection-
-/area-
-area-
-name-white square 1-/name-
etc...


Being extensible, various tags could be optional or not. So you could define each area's spatial arrangement, if needed.
It will be necessary to be able to specify adjacency for irregular areas, but will be tedious to do it this way for regular grids. I'd like to have grid elements for this, where an anchor point, plus a number of rows and columns, etc. are given.

Quote:
*EDIT* what a pain not being able to enter chevrons
I found, after some trying, that I could type them using &lt; and &gt;, which doesn't make it much less painful doing so.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Joel Uckelman
United Kingdom
Durham
flag msg tools
Microbadge: Vassal playerMicrobadge: GrognardMicrobadge: Open Source programmerMicrobadge: Linux userMicrobadge: Beer fan
doerrhb wrote:
This is a great start! Here are a few additional ideas to consider:

Dials

Games like Thebes, El Grande, Civilization and Dune have discs which need to be spun to reveal values. I propose a specific counter format which defines an image that rotates at a specific angle on top on another image, at X degrees per rotation. When the piece is rotated, it will remain on top of the image below it, and rotate at the variable degree interval.
(There are discs in Civilization? It has been some time since I looked at my copy, but I don't recall any discs.)

It's unclear to me whether this is something we need to represent as it is, or if it can be represented equivalently in some other way. (One unique component which has occurred to me that would be problematic is the tower from Wallenstein.It's stochastic, but not in an easily modellable way as dice are.)

Quote:

3D Objects / Rotation in another Axis

Rotating a 2D object is fairly straight forward, but it is entirely different to rotate a 3D game object on a virtual table top. Rotating a Zombie figure (for example) usually means that after 180 degrees of rotation, the figure looks upside down (standing on its head) instead of facing the other way. That's why it would be better to define a series of images, taken at different angles, that could be scrolled through when a 3D object is rotated. Instead of the same image being manipulated, you would be flipping forward and backwards from images X to X+1 or X-1, with an eventual loop back to X. The effect would be user defined with the number of angles (e.g. using compass directions: N, E, S, W)
I hadn't been thinking about 3D objects... Hmm.

Quote:

Yahtzee Style Dice Management

Stacking Behavior

Two Sided Pieces with Hidden Values

Randomness Generators

Counter Values
These are not static features of the game components. Rather, they are rules-governed behavior. I want not to mix these two.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Joel Uckelman
United Kingdom
Durham
flag msg tools
Microbadge: Vassal playerMicrobadge: GrognardMicrobadge: Open Source programmerMicrobadge: Linux userMicrobadge: Beer fan
peterb12 wrote:
(4) I think the "bounds of a cutout" think is a great example of something that sounds like a convenience for module developers but which will turn into a nightmare if it's actually part of the file format.
There's already a virtual tabletop program (ZunTzu) which has something similar in its file format, and is hasn't been problematic there. Why do you think this will be problematic? Could you give an example of a potential problem?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
David Kershaw
Ireland
Belfast
Northern Ireland
flag msg tools
designer
publisher
WARGAME!
badge
Lines of Battle: Quatre Bras 1815. Brunswick hussar.
Avatar
Microbadge: Miniatures wargaming fan - NapoleonicMicrobadge: I've played games in Northern IrelandMicrobadge: Autism AwarenessMicrobadge: I love running!Microbadge: Wargame Design Hobbyist
Instead of:
Quote:

<img id="1" src="counters.png" />
Why not:
Quote:

<img>
<id>1</id>
<src>counters.png</src>
</img>
I'm not sure, but isn't the latter more machine readable?
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Jerome Bonnet
France
RUEIL-MALMAISON
flag msg tools
badge
Avatar
Microbadge: Marnaudo's Game Reviews fanMicrobadge: iPad enthusiastMicrobadge: WargamerMicrobadge: Dungeons & Dragons playerMicrobadge: ZunTzu player
Joel, you should try to determine what will be the minimum skill level expected to design a game box. Obviously the lower is the better.

Most people have no idea what a color space is or what an alpha channel is. Actually most people don't understand the differences between JPEG and PNG.

1 - About masks

I've never regretted having separate mask files for the alpha channel in ZunTzu:
- it is easy to understand, easy to work with, and can be produced with the simplest bitmap editors.
- a PNG mask is usually compressed in a very efficient way, and it can be combined with a JPEG opaque image. JPEG is the most efficient format for scanned images.

2 - Versioning

"Is my recorded game compatible with your game box?"
To answer that question you'll need a versioning scheme.

3 - Resolution independence

My opinion is that a bitmap is resolution independent provided its resolution is given by the game box file.
ZunTzu only supports 150 dpi, 300 dpi and 600 dpi, but I could easily scale images to the nearest supported resolution on-the-fly while loading.

If you plan to support vector graphics, please make sure that a fallback bitmap rendering can be provided as well.

4 - Punching counters out

I agree with the idea of providing images for whole counter sheets instead of one image per counter. It's a real time saver in ZunTzu.

In ZunTzu 2 I plan to implement a "cookie cutter" feature: a mask image will be used to locate the counters on a sheet. Currently in ZunTzu, users can provide a mask image to implement alpha transparency, but they still have to indicate separately the location of the counters. The "cookie cutter" will do both at the same time. It will be great for non rectangular counters with overlapping bounding boxes (hexes for instance).

5 - Custom dice

Will you support all types of dice (4-, 6-, 8-, 10-, 12- and 20-sided dice)?
In ZunTzu a die is defined with a single texture image instead of one image per side. Although it works well with exotic dice I admit it may not be the most convenient solution for 6-sided dice.

6 - Extensions

A single game could reference more than one game box (extensions!).

Maybe a game box should indicate that it is dependent on other game boxes.

7 - Rights, licensing

Don't forget to include a copyright notice: publisher, author, artist...
Also you may want to indicate if it's OK to redistribute this game box.

8 - Other features

As mentioned in another post, "wooden blocks" would be nice to have (a la Hammer of the Scots). It's a planned feature for ZunTzu 2.

So far the five types of bits I envision for ZunTzu 2 are:
- boards
- counters
- cards
- terrains (geomorphic terrains, ASL overlays, Catan hexes...)
- blocks (Hammer of the Scots)
- custom dice (Battlelore)

In ZunTzu each type of bits is displayed on a specific layer: from bottom to top boards->terrains->cards->counters->blocks->dice (the order is hard coded). That's because there is usually no reason to hide a counter behind a board. Also, it is not possible to stack bits of different types together. I would understand if you chose to make that configurable although I'm not sure I would want that to change that behaviour in ZunTzu because it fits 99.9% of the cases.

All the other stuff (score counters, randomizing sacks, written notes, ...) are built-in and shared by all games. My opinion is that those widgets don't deserve to be defined in the game box, because they are not really game bits. I see them as mechanics. I'll have them defined in scenario or game files.
2 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Heath Doerr
United States
Farmington Hills
Michigan
flag msg tools
Origins 2020 Jun 17th - 21st
badge
Unplayed Countdown: 9 left to play
Avatar
Microbadge: I play with blue!Microbadge: I like to play NEW gamesMicrobadge: Origins attendeeMicrobadge: I have at least 2,000 logged game plays!Microbadge: Golden Image Uploader
uckelman wrote:
(There are discs in Civilization? It has been some time since I looked at my copy, but I don't recall any discs.)
Sorry, I should have said "Sid Meier's Civilization: The Board Game (2010)"

uckelman wrote:

(One unique component which has occurred to me that would be problematic is the tower from Wallenstein.It's stochastic, but not in an easily modellable way as dice are.)
Exactly, see 'Randomness Generator' above.

uckelman wrote:

These are not static features of the game components. Rather, they are rules-governed behavior. I want not to mix these two.
I understand your point, and I agree that rules enforcement is to be avoided. (In my game group we actually prefer playing without rule enforcement. It's much closer to the experience of playing in person.) However, without the description of, for example, Yahtzee style dice management, some games are immediately unplayable that would otherwise work without modification.

This is why games like Kingsburg and Roll Through the Ages are not available in ZunTzu, they are impossible to implement. It would be nice if common 'static features' that involve no programming (e.g. legal 'dice throws') were just part of the spec so that this doesn't happen in other tools.

Also, I do think that things like piece values should be described in the XML, because it could radically change how tools interact with the game pieces.

Imagine a 'money' counter type. Now based on the fact the two pieces have the same value, they can be arranged in your hand efficiently. Stacking would be done automatically, and you wouldn't have to inspect the stacks because a total value would be provided for you, all because of the addition of one simple XML element, that did not require any programming on the creator's part.

EDIT: Apparently the 'Code' function in BGG's forum is broken. It always previews fine, but when your code section is posted, it is always stripped out.
 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
Sam Collard
United Kingdom
London
flag msg tools
Avatar
Microbadge: LeftyMicrobadge: Functional ProgrammerMicrobadge: I was here for BGG's Tenth Anniversary!Microbadge: I love symmetryMicrobadge: "After the first glass you see things as you wish they were..."
uckelman wrote:
doerrhb wrote:
This is a great start! Here are a few additional ideas to consider:

Dials

Games like Thebes, El Grande, Civilization and Dune have discs which need to be spun to reveal values. I propose a specific counter format which defines an image that rotates at a specific angle on top on another image, at X degrees per rotation. When the piece is rotated, it will remain on top of the image below it, and rotate at the variable degree interval.
(There are discs in Civilization? It has been some time since I looked at my copy, but I don't recall any discs.)

It's unclear to me whether this is something we need to represent as it is, or if it can be represented equivalently in some other way.
Objects with multiple sides - a dial with 10 settings is an object with 10 faces, one rotation for each.
1 
 Thumb up
 tip
 Hide
  • [+] Dice rolls
1 , 2 , 3 , 4 , 5  Next »  [11] |