Programming in Breadth – Introduction

July 17th, 2017

All common mainstream programming languages work essentially the same way. You the programmer write instructions that eventually get executed or processed by the computer. The majority of instructions are declarations, computations, tests, and loops.

For now, think of declarations as instructions that define specific individual things. For instance, a piece of software might declare that Tom is a male human being. Once that declaration is done, Tom is known to the software in some meaningful way. And as is the case for all things in this book, each programming languages facilitates declaring things in its own way.

Computations are math or math-like operations and are fairly similar in most computer programming languages. All data in a computer, even letters of the alphabet, or represented by numbers. It therefore follows that all manipulations of the data is done on those numbers. To change a letter of the alphabet from the letter A to the letter B, simple add 1.

Tests are a common thing in all programming languages. Simply put, the software will constantly be comparing things to performing different computations based on the results of those comparisons. A test might be as simple as “if Tom is older than Jane then fire Tom.”

And finally, there are loops. A loop is a set of actions that are done repeatedly until stopped. In almost all cases, there is some bit of information that changes while the rest of the steps are repeated. When a human reads a book, they are doing the same things over and over in a loop: “Read Page” is followed by “Turn Page” and then repeated over and over while “Read Page” actually entails repeating “Read Sentence” and that itself is a loop of multiple “Read Word” actions. Looping is just repeating.

This book will attempt to describe basic computer programming ideas while showing these ideas in various programming languages. And whenever it seems important, a deeper comparison of the various languages will be included. Since this is a computer programming language book, the information here will be presented as in other programming language books with the simplest and most necessary features of the languages described first and more complex or less common features described later.

Computer Programming in Breadth

July 17th, 2017

I have an idea for writing a programming book. The book would cover basic programming concepts and instead of focusing on a single language, the book would include information on at least seven different programming languages. They might be:


I’m not sure about C since C++ is a superset of C. Then again, the string handling of C is significantly different from the other languages. I am purposely excluding Objective-C and there are no other languages that I am familiar with enough to write about in a book.

I’m also unsure about including more languages. Python is popular right now and Objective-C, something I want to avoid, might be important for historical reasons. Perhaps I can include quite a few more languages and just learn those other languages as I go. I’ll give it more thought.

I’m going to try writing some blog posts with information that I would include in such a book. It’s a work-in-progress and since I have no idea how to write a book, it is likely to suck. All of the book posts will be in the “Programming in Breadth” post category.

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:

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:

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.