7 Wonders Duel – Review

July 3rd, 2017

My daughter and I have played 7 Wonders Duel twice. That’s enough to give a basic review of the game. It is certainly not enough to describe a good strategy.


7 Wonders Duel is a two player version of the 7 Wonders game. This game seems to have been invented for one reason: 7 Wonders is not really a good game for two people.


Setup and Layout

In 7 Wonders Duel, two players take turns taking cards from a central stash and using those cards for a small variety of actions. The most common action seems to be “paying” resources to “build” the card in the “city”. “Paying” is in quotes because a player need not give away resources to “pay.” The player just need to have access to the required resources to build. And “build” is in quote because the player just places the card face up in front of them wherever they way to “build” the card. And finally, the “city” is just the collection of cards in front of the player.


Resources and Other Cards

Another action the player can take is to take a card and then place it in a discard pile. This is done to get money, 2 coins per card plus some extra based on other factors, and also to keep the other player from getting that card.


One of the Eight Wonders

And finally, each player has 4 Wonders and a Wonder can be built if the player has the required resources, by taking a card and placing it face down under their Wonder as a marker that the Wonder has been built. Wonders, and many of the cards, have effects that happen immediately, and/or at the end of the game, plus provide resources for “buying” cards during the game. Of course, once someone builds the seventh wonder of the game, no more can be built!

I’ll skip the gameplay and get right to my thoughts on the game. To see how the game is played in detail, find a good YouTube video.

We enjoyed the game. It is easy to learn for anyone who plays board games now and then. For someone who only plays Sorry, Parcheesi, or games with almost no rules, it might take one or two games to really get it. We play Agricola so all other game rules are easy to us (Agricola having some of the worst written rules I’ve ever seen).


The box is small and the setup is simple. I recommend this game, at least as a game to try if you only have two players.

Interesting Beam Engine

June 29th, 2017

Interesting Beam Engine

I threw together this beam engine with the Linkage program. It is interesting because the beam moves horizontally instead of having extra links for the steam cylinder connection.

Lander with HUD and Stuff

June 13th, 2017

There have been a few improvements made to the Lunar Lander 3D Unity game since my last post. The previous to-do list looked like this:

Add a particle system to draw rocket flames.
Add a landing pad and detect a successful landing.
Add an explode-able version of the lander and blow it up if the lander lands off the pad or lands too hard or too leaned.
A game management system to load multiple levels and to provide a start screen and stuff of that sort.

The latest version of the code has four of those items mostly working.

Latest Lander Test

The particle system for the flames comes from the Unity Asset Store. It is a low-poly particle system resource I bought for a few dollars. I think that I really only need to write the code for a particle system once I need something custom. I suspect that the code is minimal anyhow since the Unity particle system handles most of the work.

The landing pad is a low-poly (low-polygon-count) cylinder with my own graphic added. The lights are the ends of small cylinders that have their light set to “unlit” or some similar setting that keeps the tiny bit of their sides or the edge between top and sides from being a different color from the top. The flashing is just a few lines of C# code to change the color every so often.

The rocket sound is another purchase, this time from a sound effects site called soundsnap. Although I bought a particle emitter that I could have written myself, I have no idea how to get or make sounds for the game. Purchasing is the only way to get what I need for the sound effects. The script for the lander adjusts the volume based on the thrust level, making it good for throttle feedback. And since the emitter changes the rocket flame emission from the thrust level, flying is pretty easy with a joystick.


Game Controller

Something that wasn’t on the original list was joystick support. It was easy to hook an Xbox One S Bluetooth game controller to the PC and use that. I use the right trigger for the throttle and the left stick for the lander tilt.

On a side note, I had a discussion with my dad about using the left stick for the pitch and roll control and the right trigger for the throttle. When I use a full size joystick and throttle control that I have for the desktop computer to fly with MS Flight Simulator X and other games, I hold the stick in my right hand and throttle with the left. And if I’m flying a helicopter in a game with that stick and throttle, I reverse the throttle so I’m pulling back/up on it to increase the throttle, just like the cyclic control in a real helicopter. And finally, in a real airplane like a small Cessna, which I have flow and have have a proper license to fly, I would always hold the yoke in my left hand with my right hand near or on the throttle. So there is no “right” way to pick which hand or finger uses which control stick, knob, or button. They all seem to feel right and completely natural to me.

Also on the original list was detecting a successful landing. This was hard. Really hard. To detect a landing, the code needed to get called when a collision is detected between one of the lander feet and the landing pad. I unfortunately call the lander feet “pads” making it a bit hard to tell what’s going on at times. I’ll need to fix that. Anyhow, instead of trying to deal with calls to OnCollisionEnter(), which seems obvious, I opted to write code for OnCollisionStay() which is called every frame and describes all of the colliding objects. The reason why OnCollisionEnter() doesn’t work is because there is no way to use OnCollisionExit() with it to keep track of collisions. What I ended up doing is naming my feet with a number and then when there is a collision in one of the child objects, like the collider objects inside of the feet, I move up the object tree and get the number for the foot. I then set a flag in an array for that foot so I can later figure out how many feet are touching. The tricky thing is that when OnCollisionExit() is called, it doesn’t seem to tell me which collision object is no longer colliding. I just clear the array and set a flag to an “I don’t know what’s touching” state to avoid incorrectly making sounds when a foot is already touching. It’s probably all wrong but it was the best I could do given no knowledge of what the collision detection functions are supposed to tell me. At least it is possible to tell with the array if all four feet are down!

I was also playing with some terrain related Unity features. I created a height map using some other programs and make sure that the terrain is flat along it’s entire edge (all four edges of a square). The terrain sits on a box of the same color making this look like the tile-in-space that I wanted. It’s nothing to brag – the terrain is boring at this point. But at least it works.

image    image


Oh yes, and I added a HUD or GUI, whatever you want to call it, to show fuel, various speeds, angles, and other info. After the video was made is when I added a lean angle indicator. The 2D elements are super easy to work with in Unity, especially since I could create a game object to hold the entire right-side indicators and then place each individual part inside of that with relative positioning.

Writing a Unity Game

May 27th, 2017

In the last few years, I would visit the B&N bookstore and look at the game programming books. I once had aspirations to build a highly detailed railroading game with more realistic train and car movements than any retail game of that sort. I even worked out some of the logic for managing trains, cars (boxcars, not Toyotas), track, and destinations, while having clever path-finding mechanisms, etc. But my more recent inclinations have been to just get anything working in a 3D rendered world.

Image result for rectorsquid train

Image result for rectorsquid railroad

Train Game Experiments

This is where Unity comes in…

I’ve played more than a few games programmed using Unity. Most recently it was Human Fall Flat, a game that is hilarious fun for two people. I finally broke down a few days ago and installed the Unity tools.

Image result for human fall flatI was surprised that Unity is not a framework like a C++ wrapper of DirectX or a cross-platform toolkit like QT. It is actually an IDE driven construction tool where you can create a fully runnable program without writing a single line of code. At least I think so since I have not tried to build my project yet and run it as an executable. But you can defined enough of the environment and objects to have something interesting happen while only dragging-and-dropping objects into the editor and then clicking on properties to make them do basic stuff. No code is needed to make a ball roll down a hill.


Unity IDE

I worked through some of the Unity ‘Tanks’ game tutorial that is shown in something like 8 parts on YouTube and with the project files all available with Unity when it is installed. After tiring of it and making a mistake that I didn’t feel like fixing, I decided to try something of my own. This is where 3D Lunar Lander comes in. Read on…

Lunar Lander was a stand-up arcade game in the 1980’s that used a vector graphics display and some custom controls. The game displays a small lunar lander vehicle that is clearly falling from orbit over a rugged non-moon-like landscape. With limited fuel, the object is to land on a landing pad to score points. Do that and you get a new landscape and another chance to land on a different set of pads. All of this is shown like a side-view platform game drawn in thin lines. Eventually, there is no fuel left and the game is over.


Atari Lunar Lander

The first challenge in using Unity was to get something moving. I opted to put a cube into my scene and a flat surface for it to land on. This was easy and hitting the play button in the Unity IDE resulted in the cube falling onto the surface. I Added a script to the cube so I could add inputs and some values for thrust, pitch, and roll. The Thrust was easy to handle by just applying a force vector to the RigidBody part of the cube. A RigidBody make a game object respond to stuff in the game world. I think that buildings and rocks don’t need a RigidBody. Hitting the play button and then hitting the up arrow resulted in the cube rising above the surface. Voila, a game is born!

First Unity Experiment

The next challenge, that I spent hours on and is the most interesting part of all of this, is the lander controls. I wanted to pitch the lander when the A or D keys are pressed (forward and backward respectively) and roll the lander when the W and S keys are pressed. This doesn’t work like I wanted because the built-in rotation math rotates the pitch and then the roll. But after the pitch is changed, the roll axis is tilted and the roll doesn’t wok as expected. After a good nights sleep, the idea came to me to think of this differently. Think of it like trying to mimic the movement of a joystick. A joystick may have pitch and roll numbers coming out of the electronics but superficially, the stick is tilted in a direction and nothing more. The clever idea was to create a game object and stick the lander in it. When the keys are pressed, the pitch and roll values are used to come up with an angle to lean and an amount to lean in that direction. I simply rotate the game object to the desired angle and rotate the lander inside of it the opposite direction. the end result is that the roll axis is rotated to be along the direction of lean and applying just a rotation of just the one axis on the desired amount works perfectly. The lander never seems to rotate but the axis of the lean rotates.

First Unity Experiment

Of course there were other challenges to this. If the code does interpolation (LERPing) then the changes to the lean direction and lean angle can screw things up and cause jumps in the movement. If the amount of lean is changing to zero, I simply leave the direction of the lean at it’s previous value. That way, leaning to a straight up position from the leaned backwards position doesn’t cause a glitch when the new lean angle becomes zero.

The next steps in any order will be to:

Add a particle system to draw rocket flames.
Add a landing pad and detect a successful landing.
Add an explode-able version of the lander and blow it up if the lander lands off the pad or lands too hard or too leaned.
A game management system to load multiple levels and to provide a start screen and stuff of that sort.

Speaking of terrain, I have not figured out a good way to make terrain. I want to go with a low-polygon style for the terrain in case I decide to build this for mobile platforms. Right now, it’s just running on Windows. I tried to use the built-in Unity terrain system and it’s ok. The problem is that I have no idea how to add sides to a small section of terrain to make it look like a “tile.” In the image below, you can see that there are sides to the terrain (someone else’s) but that’s not that easy to achieve, so far.


Terrain ‘Tile’


Low Poly Terrain ‘Tile’

I think I’ll worry about the tile terrain thing after I get the landing pad system working. In fact, I can worry about the terrain tile thing last if I want to. But I would like to solve it so the game starts to look like I expect it to look when finished.

It will be an interesting challenge to finish the game even if it has just one level and no start screen or level selection.

Wherever this takes me, it’s been a few few nights getting the lander to fly!

Linkage 3.5 With “Servos” and Pinnable Actuators

May 6th, 2017

The new Linkage 3.5 is now available. It has connector settings to make a rotating input anchor oscillate between two angles (the first always being zero) with a settable starting position that also gets set automatically when pinning the mechanism.


There is also a new start position setting for linear actuator links. This also gets set automatically when the mechanism is pinned or can be set in the link properties.


Links to the download files are here: http://blog.rectorsquid.com/linkage-mechanism-designer-and-simulator/.

These are brand new little tested features so please report problems if you see them. I opted to release this instead of doing a beta test because no one uses the beta versions but me. Anyone interested in testing these features for me can just try them and see if anything goes wrong!

New Linkage 3.4.7 With Oscillating Inputs

April 25th, 2017

Get it here: http://blog.rectorsquid.com/download-linkage/

I just added an Oscillation Limit Angle to the connector properties. If set to something above zero, the input will oscillate back and forth to that number of degrees and back. This number is always positive so you must use the RPM value sign (positive or negative) to specify the direction of rotation, not this limit.

test (3)

Writing Software For A Living And For Fun

April 19th, 2017

Last week, I spent an evening fixing some bugs in the Linkage program. It’s a bit buggy since I added a bunch of complicated features like gears and fastening. Writing software is hard to do well but not hard to do badly. I once had to tell someone, in regards to some software having a bunch of bugs, that the software in question had more moving parts than the space shuttle and was written by one person over a few years. the effort put into the software was probably 0.00001% the effort put into building the space shuttle.

I forgot to publish the Linkage update so I’ll do that tonight. A few of the bugs were just annoyances that cropped up due to my not writing good code. For instance, I had added data to the linkage files that listed the selected connectors and links in order, instead of relying on a flag on each connector or link. But then the software processed the list front to back and ended up reversing the selections when doing an undo operation. I simply forgot at the time I wrote that code to check the order and do it right. It’s hard to do that sort of thing right when there is nothing in the code that is a reminder that the order is meaningful or that it might ever be backwards.

I did a little research last night on how I might make a simulation of a board game using HTML5. HTML5 is a shortcut for “JavaScript using HTML5 and maybe CSS3 features.” It’s the panning and pinch-to-zoom that is the hard part. I might just use SpriteKit for iOS. Speaking of iOS, when I typed “iOS” in an email using Outlook 2016 on Windows 10, the text got changed from “iOS” to “Ios” and then the stupid software automatically turned on the caps lock. WTF is with that? I should mention that a board game simulation is really just a computer game that is limited to interactions that could also be done with physical pieces on a physical table. It’s not really any sort of simulation.

The boss just asked about the time I would need to port a Windows client-server business app to iOS. I recently finished 90% of a project to port the same app to the web and the last 10% is being a bitch. The JavaScript to display the app UI was fun and the Java on the server to create the pages and deliver the data was almost fun. The feature to let users save their data and then load it up later, is not being so much fun. Mostly, it’s difficult to put a lot of effort into what seems like a badly-thought-out feature. I just can’t come up with an elegant architecture for this.

I am not prolific like some software guru types. There are people out on the internet that have published large numbers of interesting software experiments. But I still write a lot of software for fun on the side. I knew programmers that didn’t even have computers at home – it was clear that they were not really interested in programming and just worked in that capacity to have a job.

So the plan is to finish this web interface to the client-server business app, write an iOS version of the app, keep the Linkage program up-to-date, write a board game style app for iOS, keep working on the physical version of the board game (I’m designing the game itself while using the simulation as a way to test it), and do non-programming stuff like finish an almost done RBS, work on a new RBS, and play a bit of Forza Horizon 3. It’s going to be a busy spring and summer.

New RBS “Thrown Together”

April 12th, 2017

No, it’s not titled “Thrown Together,” that’s just a description of how I started it. As you can see in the video, the base is the working-platform for a previous sculpture (now sitting on a sheet of acrylic) and the motor mounts are just wood bits.

First Full Test


Solid State Track Switch


Solid State Track Switch

This machine has a solid-state track switch. It is “solid-state” because it has no moving parts. The momentum of the ball keeps it moving along the outer upper track until after the two tracks are merged into one. But when the ball travels back through the switch, it does not have the momentum to stay against the outer upper track and it follows the lower path. There is no noise because the tracks meet gradually and the ball never falls from one track to the other – it is simply on both tracks at the same time for a moment. Any clunking noise in the video is coming from the motorized lift picking up a ball and a new ball falling into place at the start of the track. it is unfortunate that the clunking sound happens at about the same time as the ball going through the switch.

After taking the video and pictures, I removed the sticker form the motor and blackened the casing. I also blackened the track. Once the sheet of clear acrylic is ready at the plastic shop, I’ll be one motor-mount and on-off switch away from being done.

Gears for Lifter #3

March 21st, 2017


The next lifter needs a crank that oscillates for about 200 degrees of a circle. The only way to achieve that is to use a motor crank to drive a crank on the big gear that then drives the small gear and its crank. 100 degrees of movement of the crank on the big gear is then 200 degrees of movement of the crank on the small gear.

See the video if it doesn’t make sense:


Send Complex JS Data In A Web Page

March 17th, 2017

I had a dilemma; how do I send a bunch of complex JavaScript data within HTML without using AJAX. The server is running Tomcat and the HTML content is generated by some Java classes triggered by a servlet. The funny thing about this is that once I solved the problem, I realized that I had solved it once before back when I created my trip log map page. But this new problem seemed on the surface to be different so the solution evaded me for a day or two.


Trip Log Page

The requirement is that a web page be sent to the browser and that a bunch of processing be done to manipulate HTML form content in the browser with no further server interaction. The data consists of rules for when to show and when to hide various form fields, as well as data to populate lists in the form conditionally on the selections from other lists. Imagine a web site where you pick the make of a car (Ford, Chevy, Toyota…) and then the next list contains only models from the selected car company (Bronco, Mustang, Corvette…). How would all of the models of all of the car companies be sent to the browser so that an extra query isn’t needed for the model field each time the make selection changes?

The company that I work for uses AJAX for another “product” but this seemed impractical since generating the web page takes a lot of processing time to get and parse data from a database. Doing that parsing each time a single field changes is not at all efficient. Plus, the other “product” usually has a few large lists on a page and my forms might have a hundred.


Option 1 was to use data attributes available in HTML5 and store all of the extra stuff that way. I opted against this because I would need to convert a two-level tree structure into some form of string that I could parse on the client. I hate writing code that parses or compares strings over and over again because I was schooled in writing very efficient code back when I worked on high speed search algorithms in the biotech field. In that field, writing one extra “if” test in a loop could make a product too slow to sell. This option would have made it easy to find the data content while looking at the visible tree of form fields, which would have been a nice side-effect.

Option 2 was to use the DOM by storing the data in div elements as if it were just more HTML content. The data elements would be hidden and would just be available to be read by the JavaScript when needed. This seemed like a pretty good idea because the data would be human readable during the development process. I rejected this option because I have no idea how a lot of extra hidden content would affect the page rendering. Like the first option, this option would have made it easy to find the data content while looking at the visible tree of form fields.

Option 3 was actually a bunch of failed ideas that never got past the first threshold of analysis. For instance, I could store XML data in an HTML5 data attribute or in one of those weird data elements that I have never used before. Or how about having a separate HTML select field for each variation of a list and then just displaying the one that has the appropriate data? That’s just another way to use the DOM and would add some work to hide and disable the unwanted “select” fields.

Option 4 was to generate some JavaScript code and pass it that way within a script element. It’s funny that this was not the first option since the trip log page does almost that exact thing. And now that I am writing this, I see that I didn’t do the best possible job on the trip log page because I generate, in PHP on the server, a JavaScript function that creates an array of trip information and calls functions to add data to the trip object. With this new Java project, I am just generating a global variable declaration and initializing it using literal data. I was just not as aware of how to declare and initialize a tree of complex data objects in JavaScript before now.

Above is a rough estimation of what the data will look like. This is taken from a working test case that doesn’t have a lot of content. But the idea of declaring the global variable and initializing it to literal objects, should be fairly clear. I manually added a lot of space and indentation to make it a little more readable in this example.

The final step in this development task is to write a JavaScript function that finds each of the form fields on the page and actually store a reference to the appropriate field object in this tree. Or maybe I’ll do it both ways and add a reference to the input field within this tree. That way, when a function gets called that a list selection is made, it will be easy to step through the form fields and change the field contents appropriate. It may not be obvious but the HTML form fields all have an “id” attribute that matches the “id” in this data structure. So making the cross reference won’t be hard at all.