Check out Atomic Chess, our featured variant for November, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Comments/Ratings for a Single Item

EarliestEarlier Reverse Order Later
Smess. Produced and sold in the early 70's by Parker Brothers. Arrows on squares determine direction pieces can move. (7x8, Cells: 56) (Recognized!)[All Comments] [Add Comment or Rating]
🕸📝Fergus Duniho wrote on Fri, May 10 09:10 PM UTC in reply to Fergus Duniho from 09:06 PM:

Also, I added the same code to the Smess diagram, and it is now tiling with the pieces on it. Since I made those pieces for a larger board, I think the board image and the pieces are not at the same scale.


🕸📝Fergus Duniho wrote on Fri, May 10 09:22 PM UTC in reply to Fergus Duniho from 09:10 PM:

I changed the board image to the one that goes with the pieces, and it looks a lot better, but there are still some alignment issues. The spaces on the board are rectangular with a width of 83 and a height of 73, but the squareSize parameter seems to expect one value that gets used for both height and width. Is there any way to specify height and width separately? In the meantime, I'll make a resized copy of the board with square spaces.


🕸📝Fergus Duniho wrote on Fri, May 10 09:30 PM UTC in reply to Fergus Duniho from 09:10 PM:

I created and used a new board with 83x83 spaces, and I set squareSize to 83, but now the board is starting halfway into the first rank and tiling on the right side. What can I do to fix that?


🕸📝Fergus Duniho wrote on Sat, May 11 12:38 AM UTC in reply to HaruN Y from Fri May 10 01:43 AM:

I got your diagram to display correctly and added it to the page with some modifications. To make the board display correctly without tiling, I removed the firstRank assignment and set borders to 0. I replaced the graphics with ones I created for Smess. The board is a stretched version of one I made for Game Courier, and the pieces are the ones I made for Storm the Ivory Tower, which have smoother edges. I set useMarkers to 1 to stop it from changing the background color of a space when highlighting it, but this doesn't work for moves made by the opponent. Since it is important to not hide the arrows on the board, it would be helpful if useMarkers would also change how the opponent's moves are highlighted.


🕸📝Fergus Duniho wrote on Sat, May 11 05:03 PM UTC in reply to Fergus Duniho from 12:38 AM:

Because the Ivorytower pieces looked a little small on the board, I reduced the size of the board from 83x83 squares to 73x73 squares. The original board had 83x73 squares to give it a more square shape with a 7x8 layout, but the 73 pixel width works better for the Ivorytower pieces, because they can now fully cover up the oval on some spaces that names the piece starting from that position. I also tried 60x60 spaces, as that is the size used in Storm the Ivory Tower, but the Blue Brain was covering up too much of the forward arrow on its space. So I reverted to 73x73.

While the Ivorytower pieces do look better, they are still rough around the edges. and I think they would look better as SVG pieces.


H. G. Muller wrote on Mon, May 13 06:58 AM UTC in reply to Fergus Duniho from Fri May 10 09:06 PM:

Would it be a good idea to add this to global.css?

I think it would be good to have no background color at all for <tr> elements. I see no legitimate use for it. If it is desirable to see the background color of the page for <table>, <tr> or <td> elements, they could simply be transparent. Then the page background would shine through. If it is desirable to have a color for table cells that is different from the page background, then this should be specified for the <table>  element, and the <tr> and <td> cells can be transparent to show that color in every cell. This way it is prevented that background colors of a foreground element would cover/hide non-default changes made in the elements behind it.

I guess that 'inherit' is not a sensible setting for elements like <td> and <tr>, which always have a <table> as (grand-)parent element. Because these would automatically get the color of the parent by being transparent. Inheriting the color just causes problems by eclipsing any background-image of the parenet element; it allows the background-color of the parent to sneak in front of its background-image.

In the I.D. I made the cells transparent by specifying an empty string for lightShade and darkShade. This worked, but I don't know if it is the official method (and thus whether it will always keep working). I now learned that in general (semi-)transparency can be set in HTML by using a notation

rgb(R G B / A%)

where A is the opacity (100 = opaque, 0 = fully transparant). Perhaps I should make the Diagram script recognize the empty string as a color spec for the square shades, and replace it by rgb(0 0 0 / 0%).


H. G. Muller wrote on Mon, May 13 07:14 AM UTC in reply to Fergus Duniho from Sat May 11 05:03 PM:

With the current coloring scheme it is very hard to distinguish occupied squares from empty squares; the pieces blend in too easily with the bright square and arrow colors. I would recomment to decrease the saturation of all the board colors by at least 50%. E.g. by giving the image a 50% (or even 70%) transparency and have a whitish background shine through.


7 comments displayed

EarliestEarlier Reverse Order Later

Permalink to the exact comments currently displayed.