“Roundabout” Game Design

August 11th, 2016

I don’t think that I posted anything about designing a board game. My daughter and I have been playing lots of board games recently, maybe to be able to play together and not with a screen in front of us, and then one day I started creating a board for a game.


Our game doesn’t really have a name. I just picked “Roundabout” for this post because the game is travel themed and, believe it or not, it’s round!

This game is loosely based on Tokaido. I took some ideas that I thought were really great and threw out some even better ideas (because Tokaido is a great game and stealing is bad) and came up with this.

Design Process

I started out wanting a round board. There is something cool in having a circle with little circles around it. At least for me, I find it aesthetically pleasing. So I figured out about how many spaces I needed around the board, 36 being a good starting number since each is 10 degrees from the next. Then  draw a bunch  of circles. I didn’t keep a good pictures of that first game board, just this piece of a screen shot:


The first version of the game just used some initials and geometric shapes for the spaces on the board. I used old business cards to write symbols on them. We played it for a few turns before thinking it would work and that it also sucked without proper cards.

We recently made the new graphics (the first picture in this post) and printed cards on card-stock with front and back images to match the spaces. Here’s some samples of our graphics taken from the instructions:


We are now trying to refine the rules. There are two things that are giving us trouble:

  1. How does the game end?
  2. How does the player move onto and off of a side path?

We have been using the Start space as the End space on the board. As soon as a player reaches that space, the game is over.

For the side paths, we tried moving out on a side path and then back in, stopping on each space going in both directions. We also tried to go from the end space on the side path right back to the next space along the other side path or along the main path. That was hard to follow while playing. Even going out and back was hard to follow. The latest idea is to jump from the end space back to the space on the main path, which will always be empty. Then no active space gets repeated while taking a side path.

We’ll have a few other players give us some feedback this weekend. I look forward to reporting what they think and also posting about how the game design progresses.

Link Triangles Working, Sort Of…

July 29th, 2016

I have a first draft working for the link triangle simulation. Like I said recently, I am opting to support the most common type of link triangle configuration and ignoring all others. Here are videos of the two variations of supported link triangles:

What I did on this first try is to simulate the triangles, which are identical in configuration and only different is where the fixed connector is versus the moving connector, is to determine the length from the fixed connector to the other end of the link triangle.

Where things go wrong is after that. After that length is determined, the code just moves the moveable end of the link triangle by rotating that link that it attaches to. Then the simulation continues from there and on another pass, the links within the triangle can be simulated normally. Well, except that the end of the link triangle often oscillates and the information about the link triangle is gone at that point. this causes some weird artifacts in the movement as you can see in at least one of the videos.

The way to fix this is to somehow remember the angle of link connections at one of the connectors within the link triangle and use this for simulating the triangle once its length is determined. Or maybe I just need to figure out which of the two links, one being an actuator, needs to be processed first is the next step of simulation. I’m not sure yet.

But it’s close to working! Yeeha!

Just going to kludge the link triangle thing for now…

July 27th, 2016

I decided that I’m going to make an alternate link-to-link simulation function that accepts a link triangle as one of the links. It won’t work for both to start with because, well, no one makes mechanisms like that.

The fact is, there’s only really one type of link triangle situation that people might use. They are probably not going to stick an actuator on a link in a way that the end of the actuator slides on that same link as the other end is mounted. They are probably also not going to connect two link triangles with actuators together at the end of two actuators.

Here’s what I want to make work:


And here are some things that still won’t work after this change:


imageimageAlthough I do want to come up with a more flexible simulation algorithm that handles all of these, right now I will add some code to handle the one special case of a single link triangle connected to something that is not a link triangle. We’ll see how it goes.

New Linkage 3.3.5 Available

July 14th, 2016

I got my new code singing certificate and I fixed a few minor bugs. Super short dimension lines were becoming infinite due to the space calculated for the arrow heads. There was also a problem with gear and link rotation angles that went wrong after about two rotations of a gear fastened to a link.

So go get a new version if you need it. The Linkage page, available form the right column of any of my blog pages, has the links to the XP and newer Direct2D variations of the software.

Working with Link Triangles

July 14th, 2016

I have a plan. It’s not a very good plan, but it is a plan.

imageThe mechanism above presents a problem that I have written about a few times in the past. The EGJ triangle is what I call a “link triangle.” It is a set of links that when simulated, act like one larger link. Although I added some code to do some simple link triangle simulation, it is not at all what I need. That code was more of an experiment to see if I could detect a link triangle and then use it in a simulation. But it could not handle the actuator seen here.

The reason that the existing link triangle simulation code can’t handle the actuator, and is far too simple anyhow, is because I used a modified function to replace a regular link with some triangle link info while looking for links to rotate to meet each other. There was no way to actually simulate the actuator when creating the link triangle and no way to handle sliding connections. Damn those sliding connections – they made all of the simulation code 10x more complicated that it was before adding the sliding connector feature.


Above is another mechanism that has the same link triangle sort of problem. This one is a little more interesting because it only has two links in the “triangle” and one of them is an actuator. The simulation is easy to do on paper but is a very special case in the software.


Now it’s just getting weird. Again, this is easy to simulate on paper but is yet another weird special case. The link triangle is formed by connectors CGE but the shape of the link triangle is defined by the actuator that is not a leg of the triangle.

So first things first. The only way to simulate this sort of thing is to figure out the relative positions of the various connectors based on the actuator length. Remember, what the mechanism looks like before it starts is not what it looks like at any step in the simulation. I will need find link triangles, and that non-triangle variation with the actuator and slider, and simulate the parts as if most of the connectors are at a fixed location. then I can create a temporary link of the new shape and use that in the normal simulation code to see how it interacts with the rest of the mechanism. I would need to save the temporary link and find other link triangles before doing any full mechanism simulation because two link triangles might be connected to each other.


But first, I need to change the entire data structure of links and connectors. Look at the simple mechanism above and then at the XML in the data file:

    <program zoom="1.000000" xoffset="-10" yoffset="0" scalefactor="1.000000" units="Millimeters"/>
     <connector id="0" selected="true" layer="16" x="-156.734694" y="54.666667" anchor="true" color="16711680"/>
    <connector id="1" selected="true" layer="16" x="-117.551020" y="166.000000" color="12632064"/>
    <connector id="2" selected="true" layer="16" x="-78.367347" y="54.666667" anchor="true" color="32768"/>
    <Link id="0" selected="true" layer="16" linesize="1" color="16711680">
        <connector id="0"/>
         <connector id="1"/>
    <Link id="1" selected="true" layer="16" linesize="1" color="12632064">
        <connector id="2"/>
        <connector id="1"/>
        <connector id="2"/>
        <connector id="1"/>
        <connector id="0"/>
        <link id="1"/>
         <link id="0"/>

Notice that in the data file above, and in the internal data structures for the mechanism, there is a single connector for the place where the two links are connected. This was a tough design decision to make and it turned out to be a bad one. What it does is it lets the user select and move a connector with very little code. But it also makes it impossible to treat links 1 and 2 completely separately. If the code needed to move connector B to make link 1 longer, like if it is an actuator, but not change the location of connector B for link 2, it is impossible; there is only one connector B. This makes it impossible to create a temporary link in place of a link and then simulate it using different connector locations.

The plan as of a few minutes ago was to change the entire data structure so that each link keeps track of the connectors as separate objects in the code. There would be two objects for connector B, one belonging to each link. They would then point to each other. I think that these per-link connectors will not be connectors like I use now, they will just be some intermediate data structures that keep track of where they connect and also keep track of the existing connector data object. Ugh, too many objects in the data structure for the mechanism gets a bit unwieldy (if that the right word). It makes it hard to maintain the code when there’s so much data to manage and use during any operation.

So to put it another way, the connection points of a link will have their own positions along with a reference (C++ pointer) to the regular connector object. The regular connector objects will no long have a position used during simulation, just during drawing of the mechanism. I can then create a temporary link from a link triangle and have it connect to other links without worrying about altering the shapes or sizes of those other links.

Now to actually change the code. That’s going to take more than a few hours I suspect.

Linkage in a Virtual Machine on Mac

July 6th, 2016

FYI, I was able to easily install Windows 10 running in a virtual machine on my MacBook Pro. I got a trial copy of Parallels and it handled the Windows 10 installation seamlessly. I already had a Windows 10 product key so it was free (so far). And the best part is that the Linkage program, after a little extra startup delay, works fine.

As a side note; I just sent my verification data to Symantec and they should get me my new code signing certificate any day now. I am anxious to publish an update to the Linkage program because of a few small bugs that I fixed recently.

No Linkage For a Short Time

June 26th, 2016

Somehow, I missed that my code signing certificate was about to expire. And Symantec needs me to do the whole notarized identification thing to renew it. This means that I can’t produce a new Linkage program with a bug fix that I wanted to distribute, at least not for a week.

The bug is not really a big problem. It turns out that if a dimension line is short enough, making room for the arrow heads causes the line length to get screwed up and the line draws itself right of the page and maybe to infinity. Just ignore it if you see it.

I also discovered that sometimes drawing elements that are not part of the mechanism should be drawn without dimensions. I got a mechanism file from a user and saw that a bunch of extra junk shows up when drawing layer elements are present and complicated. I don’t know why they needed all of the drawing elements, maybe to use for aligning the mechanism, but the auto-dimensions look crappy in this case.

So the list of ideas gets bigger:

Allow auto-dimensions to be disabled for specific elements.
Allow auto-dimensions to be enabled/disabled by layer.
Allow drawing layer elements to be including in the parts list.

Art of Time Video

June 11th, 2016

I captured a few stills from this video because the work is just amazing. Credit for the stills goes to the people who produced the video; Seiko. The comment on the video says “The meticulous attention to detail and artistic beauty of the time.”


Last Beta Before Release

June 7th, 2016

This is the last Beta version of Linkage 3.3.

Get this Beta version here: http://www.rectorsquid.com/temp/linkage.msi

The video seems to be working properly and so does the image export. It’s almost time to release the new Direct2D version of the Linkage program. And wow do those smooth lines look great! If anyone sees something wrong, send me a screenshot.

I will keep making the older version because it should work with older versions of Windows if the new one doesn’t.

Wow, that is a cool tool…

June 2nd, 2016



I would love to make stuff this good looking.