Zovirl Industries

Mark Ivey’s weblog

The 12 Most Useful Knots

Want to get better at tying knots? Have you tried learning some knots only to forget them later? Want to be able to remember how to tie a knot when you need it?

Sign up to learn about a new set of knot-tying lessons I’m developing:

There are hundreds of different knots, but many of them are specialized knots, or perform almost the same function as other knots. You don’t need to know them all! In fact, you can get through most situations with only 12 knots, if you pick the right 12.

It is a lot easier to remember knots if you only need to know a handful of them. Also, it turns out there are similarities between the knots. You can exploit this to help remember them, by learning to see the connections between knots. You end up building a web of knowledge about the knots so they stick in your memory. My goal is to teach you the knots in a way that helps you remember them so you don’t forget them.

Sign up to get the first look

I’m developing lessons to teach you how to tie these 12 useful knots. If you want to influence their development, get notifications about progress, and get sneak previews of lessons before they are published, sign up for the mailing list!

I won’t spam you with other offers or give your email address to anyone else. You’ll only receive information about tying these helpful knots.

How is this different from other knot sites?

There are several other sites about tying knots, and they are quite good. However, they cover lots of knots. This is helpful if you’re an expert looking for a specialized knot, but if you just want to know the best knots it can be overwhelming to have a list that goes on for pages.

These lessons approach knots differently. * Instead of a hundred knots, I show you 12 knots. * Instead of all kinds of specialist knots, I only show you generalist knots: the ones you can use over and over in many different situations. * Instead of just showing you how to tie the knots, I show you how to commit them to memory so you never forget them. I show you how the knots are structured, how they are related to other knots, mnemonics for tying them, etc.

My goal is that once you go through the lessons and remember the knots, you never need the lessons again. Hopefully you’ll know (and use) the knots for life!

I’ll also show you how to apply the knots by highlighting ways I use them around the house and in every day life. I’ll cover how to use them when hiking and camping too, because knots are so useful outdoors.

What is the lesson format going to be?

The lesson format isn’t set in stone yet, and you can influence the outcome by signing up for the mailing list. I’ll be sending out polls about how you learn best and how you’d like to see the information.

Would you rather have web pages? An eBook? Videos? Perhaps an app on your phone?

Sign up and you can help decide:

Nanoblocks Piper Cub Instructions

Here are instructions for building a model of a Piper Cub airplane from Nanoblocks.

The Cub is a small 2-seat plane that's been around since 1938. Top speed of the original model was 85mph, though later models increased the size of the engine and got the top speed up to 130 for the Super Cub. The body of the plane is incredibly narrow, with one seat in front of the other instead of having the seats side-by-side. The instrument panel on early cubs was incredibly simple: RPM, airspeed, compass, altimeter, oil temperature & pressure, and slip indicator. That's it.

I designed the nanoblock model starting with the wing. The only way to get the wing skinny enough is to build it with the studs facing forward. Studs forward is also useful for attaching the propeller and getting the landing gear at the correct angle, so the whole plane is done with the studs forward instead of up. The size of the model was decided by the number of yellow bricks I had.

Hope you enjoy building it!

Triple Town Economics (How to Never Run Out of Turns)

When I first started playing Triple Town I was annoyed that I kept running out of turns. It felt like the kind of dirty trick a Facebook game would play. Actually, I just wasn't good at the game. It is possible to earn enough coins from each game to pay for your next game. It also makes the game more fun: instead of bears being troublesome creatures messing up your high score, they are profitable resources to be exploited.

Ironically, now that I don't need unlimited turns I bought them anyway because I want the other game modes.

The economics

  1. Turns cost between 0 and 4.75 coins/turn, depending on how much play per day (because you get 150 free turns per day). Example: 150 free turns plus buying turns twice: 550 turns for 1900 coins, or 3.45 coins/turn.
  2. You get paid 1 coin per turn (at the end of the game). You also get paid based on your city's rank, but I'm not sure what the formula is so I don't worry about it.
  3. Mansions pay 100 coins each (at end of game). Castles pay 200 coins, but require 3 mansions, so it is better to just keep the mansions.
  4. Treasure chests pay 500 coins.

For the example 550 turn game, you need to make 1900 coins total. You'll get 550 coins (#2 above). If you can get 3 treasure chests, you made a small profit. Or if you get 2 treasure chests and 4 mansions, you also come out ahead.

Further Nuances

  1. It takes 27 bears to get a treasure chest (bears -> churches -> cathedrals -> treasure), so a correctly-placed bear is worth 18.5 coins.
  2. A crystal used to combine two cathedrals to get a treasure chest is worth 167 coins (1/3rd of 500)
  3. A crystal used to combine two houses to get a mansion is worth 33 coins (1/3rd of 100)
  4. Using crystals & robots to make rocks -> big rocks -> treasure chest requires 7 crystals and 1 robot. 71 coins per crystal. You're better off using crystals to combine cathedrals, except...
  5. At the start of the game you get lots of crystals and sometimes start with a couple rocks. If you get crystals before you have anything useful to combine, the rock -> treasure route is reasonable. This can be a quick way to pick up 500 coins at the start of a game.
  6. All those crystals at the start of the game also mean the early game is more profitable. Once the crystals stop coming and the map is filling up with ninja bears, it is time to scrap the city and start a new one.

(I play the Android version of Triple Town. I don't know if the iOS, web, or kindle versions have different economics, but you could do the same analysis).

Easier Soldering with Improved Third Hand

When soldering electronic parts together, one hand holds the soldering iron and one hand feeds the solder, leaving no hands to hold the parts being soldered. There's a common tool nicknamed a third hand which helps here. The tool has one or two (or three) adjustable alligator clips to hold parts and usually has a magnifying glass to help see the work.

Mine was always a little difficult to use. The clips would fall out of their holders, and the teeth on the clips tended to bite through insulation on wires. I lived with this for years without thinking much about it, but finally fixed it. It took 10 minutes. I should have fixed it years ago.

First, following this advice from Robot Room, I strengthened the base of the clips so they wouldn't fall out. The problem is that there's a screw which clamps down on a flimsy, hollow tube and can easily crush the tube. Solution: fill the hollow tube with metal so it can't be crushed. The article suggested using a brass rod, but I didn't have that so instead I found a bolt which fit, cut it to the right length, and screwed it in.

Second, I put two layers of heatshrink over the teeth so they aren't as sharp. Should help protect wires.

These were both easy fixes. If you have one of these third hand tools, you should take 10 minutes and fix it up!

Attenuating Headphone Cable

My headphones are too loud. I have in-ear headphones which seal out outside noise and are quite sensitive. I have to keep the volume at its lowest setting, almost off, for comfortable listening. This has two drawbacks: it is painfully loud if the volume ends up at its max setting, and there's usually a hiss coming from my phone or laptop which competes with the music at the lowest volume setting.

To fix this, I made a short headphone cable which reduces the volume. This is similar to the headphones which have a volume knob or slider built into the cable, except that it only has one setting: quiet. The circuit is two simple voltage dividers, one for the left channel and one for the right channel. I found the resistor values through trial-and-error on a breadboard, just trying different values until I found some that gave the ideal volume reduction. The circuit is tiny enough to fit inside the headphone jack and it works well. I can now comfortably use the entire volume range when listening to music, and at the higher volume settings the hiss is drowned out by the music so I can't hear it any longer.

Alpha in WebGL and Canvas

I've been learning WebGL and have been confused how alpha blending works. Coming from working with the 2D <canvas> API, the WebGL behavior was was surprising to me.

(This post uses some recent HTML5 features which won't show up properly in older browsers or IE. I know Chome and Firefox will show it correctly).

The Problem

The demo below uses WebGL to draw white, gray, and black triangles in a range of alpha values, all with the standard gl.BlendFunc(gl.SRC_ALPHA, gl.ONE_MINUS_SRC_ALPHA). The results are weird. For example, why does the row of black triangles get lighter than the background as alpha decreases? If you change the background to be almost-but-not-quite white, why do the white triangles stop fading entirely?

For reference, here's a version done using the canvas API which behaves as expected and clearly shows the differences in alpha behavior between canvas and WebGL:

The Answer

As I learned from Gregg Tavares, the answer to the puzzle is that WebGL blends the alpha channel differently than canvas does. Using the standard gl.BlendFunc(gl.SRC_ALPHA, gl.ONE_MINUS_SRC_ALPHA), WebGL's blending equation for alpha is:

A = Asrc * Asrc + Adest * (1 - Asrc)

If you start with an opaque buffer and render a semi-transparent polygon, the result is that the buffer is now semi-transparent (A = .5 * .5 + 1 * (1 - .5) = .75).

This transparency allows the white background of the page to show through and blend with the WebGL colors. Putting text behind the WebGL canvas makes this obvious:

Gregg details several ways to address this, including using { alpha: false } when requesting the context:

Game Marketing Tips From GDC

I gleaned some game marketing tips from several talks at GDC this year.

Tom Francis (Gunpoint) described how to explain games in writing, while Kert Gartner showed how to make good trailers for games. The techniques are quite similar since both require efficient communication. Taken together, these two talks were filled with great advice for telling people about your game. Also, Nathan Vella (Sword & Sworcery) explained how they used consistent PR to communicate the spirit of their game to potential players.

How to Explain Your Game in Writing

Tom Francis talked about explaining a game to impatient readers. Keep the explanation short, about 3 sentences, by means of ruthless editing. Do not make these common mistakes, they waste words:

  1. Failing to explain things. Don't post a gameplay video with no commentary and hope viewers understand. They won't.
  2. Explaining artistic intent. It doesn't explain why I would want to play your game. It also uses too many words.
  3. Explaining story. A compelling explanation of your games story takes too many words. Skip it.
  4. Saying it is "innovative" or "awesome." These words mean nothing coming from the creator of the game.

Instead, you need to fit these 4 things in 3 sentences:

  1. Type of game. Just a few words. 2D platformer. Racing game with RPG elements.
  2. Coolest unique thing. Rewind time to fix mistakes. Tear down and rebuild the entire world.
  3. The fantasy. Not story, that takes too many words. Just the fantasy: You're a criminal driving around a sprawling city. You're searching for your sister in a creepy forest.
  4. Give one example of the gameplay. You fly your helicopter up the river bed, staying behind the trees to avoid detection, then sneak over the ridge to drop the commandos off at the enemy base. You drive your moped up the stairs, through the shopping mall, then jump over the embankment to get away.

Focusing on efficient communication makes it more likely you'll get your point across before the reader loses interest. Tom has posted his talk here.

How to make a good trailer

Kert Gartner explained how to make good trailers for games. Similar to Tom's points about terse writing, Kert stressed the importance of keeping the trailer short.


  1. Make it longer than 60-90 seconds. Most viewers won't watch that long
  2. Try to explain everything.
  3. Cram too much information in.
  4. List features of your game. This is boring and not a good use of precious time.
  5. Release a bad trailer. You'd be better off with no trailer.


  1. Make sure the first 5-10 seconds capture attention.
  2. Use a simple dramatic story arc. A clear beginning/middle/end structure which builds to a climax is good.
  3. Show what the game is about.
  4. Capture the style or feel of the game.
  5. Use zoom-in to focus on the important parts of busy/complex gameplay footage.
  6. Use slow-motion to help the viewer catch important parts of fast gameplay footage.
  7. Leave the viewer wanting more.

He showed several example trailers with a detailed explanation of the techniques going into each one. It would be worth going over to his blog to see the examples.

How to Keep Your PR Consistent

Nathan Vella talked about PR for Sword & Sworcery. I was impressed by how much they focused on consistency and on getting the feel & spirit of their game into their PR material.

Nathan had a couple tricks for making sure the vision for the game is communicated in the PR. First, base the PR on the vision for the game instead of the game itself. If you base the PR on the game, the vision will be watered down. It is ok to reference the game, obviously, but make sure the PR is being influenced by the vision. Second, make sure that the person who is in charge of the vision for the game is involved in the PR directly. Ideally you want your PR and your game to feel like part of the same whole. Example: gameplay in Sworcery is tied to phases of the moon, and they kept this same astronomical spirit by doing sales of the game around the solstice.

There was also the mechanical side of consistency: use the same fonts in your game and your PR material. Use the same color palettes. Use the same sound effects. Maintain a common voice between your game and your PR (and make sure all your PR uses a common voice, especially if multiple people are involved in producing it).

You can see some of this consistency in action over at the Sword & Sworcery website, where they talk about "electric computers" and the soundtrack being available on vinyl & audio cassette and where they label their search box "What do you seek?". It feels like their website came from the same weird world that Sworcery is set in.

Artisan Games

I like the idea of approaching game development as an artisan baker would approach making bread or the way a craftsman would approach making a piece of fine furniture. Making unique, high-quality products for a discerning audience. Artisan games.

There were a couple talks at GDC this year that reminded me about this, especially Nathan Vella's talk on how they making Sword & Sworcery stand out by taking taking risks, targeting a niche audience, and keeping quality high.

Unique Games

Nathan started with the business reason for making a game which stands out: There are so many games out there, it is easy for your game to blend into a sea of similar games. Making a game which stands out is a big step towards success. I also have a personal reason: I want to make something new, something unique. Games take so much time to make that I don't want to be making games that have already been done.

Making a game that doesn't stand out is straightforward: just follow convention. Do what other games do. Each game platform has a set of common trends that you can follow. Making a game for iOS? Use cartoon graphics, one or two simple mechanics, and keep the game short. Making a Facebook game? Have an energy mechanic to encourage players to return tomorrow, use asyncronous multiplayer, and nudge the player to invite their friends. If you always take the "safe" option when faced with a business choice, your game will probably blend in. If you want to stand out, you're going to have to start breaking conventions, ignoring trends, and taking risks. Nathan kept coming back to the idea of taking risks throughout his talk.

Amir Rao (Bastion) spoke during the failure workshop and mentioned a great safety net to use when making a risky game:

  1. Ask "What's been done?" Find the conventions.
  2. Do something else, something new.
  3. If #2 fails, fall back to the conventions you identified in #1.

Falling back to convention sounds like a great way to make progress if the risky innovation doesn't pan out. On Bastion they ditched a gardening mechanic that wasn't working but their game still stands out because they bucked trends in other areas of the game. You don't have to innovate on every aspect of your game to have it stand out. It is ok to stick to conventions in some areas.

Discerning Audience

Nathan specifically warned against trying to make a game with broad appeal. Yes, the payoff is huge but there's also stiff competition. He compared it to a lottery. Instead, Nathan suggested going after a niche. This lets you target your game specifically to your audience. You will be able to know your customers and know what they want. You're much more likely to stand out to your customers because you're making a game just for them. You can tailor your PR so you are speaking directly to your niche. Nathan pointed out that there are enough game players now that niches can still be huge. They've sold something like 350,000 copies of their niche game on iOS.

High Quality

The last part of artisan games: quality. Nathan said on Sworcery they decided it was safer to slip their deadline and over-run their budget than to release a rushed game that wasn't great. In the end, they found that finishing a risky game well opened a lot of doors. This echoed what Kert Gartner said in his talk on making trailers for games: a bad trailer is worse than no trailer, so either make an awesome trailer or don't make a trailer at all.

This seems especially important if you're trying to build a reputation for great games. The one caveat I would add is that it probably doesn't apply if you are just starting out. New developers usually don't have the skills to making high-quality games. That's normal. If you are new it is more important to make lots of games than to get stuck trying to make your first game high-quality. Quality will come with practice. Going back to the baker analogy, no one expects a beginning baker to make a perfect loaf. If you have the skills to release quality games, though, it seems like a sound choice to do so instead of rushing crap out the door.

Graph Land: A Graphing Calculator for Javascript, with Cows

Graph Land is a graphing calculator for Javascript. In addition to such useful features as the ability to plot Math.cos(Math.floor(x*2)), it also has adorable cows, clouds, dusk, dawn, and other such fine accoutrements which all fashionable graphing calculators in this modern age aspire toward.

Try it now

A brief account of the creation of Graph Land

A flight simulator I've been working on needed some interesting terrain for the player to fly over. I saw two solutions: use a level editor to create some interesting terrain (the manual route), or make an algorithm that generates interesting terrain (the procedural route). Making levels by hand is tedious and time-consuming, so I chose procedural terrain generation, which is also time-consuming but more entertaining.

To get rapid feedback while working on the terrain I made a simple app that plotted the output of the algorithm as I tweaked the parameters. It was basically a graphing calculator that took a Javascript expression as input. I used the app to get an algorithm capable of producing convincing hills and mountains, then moved on to work on other things.

Later, I found myself coming back to this app to visualize other things. I used it to tune the length of daytime/nighttime (a modified sine wave) in a different game. Then I needed to smoothly switch colors in another app and I knew the shape of the curve I wanted, but I didn't know what the actual formula was until I messed around in the graphing app for a few minutes and found it.

Much later, cows wandered in. Shortly after that clouds formed in the sky. Eventually the sun, showing no respect for the traditional order of creation by its tardiness, started making a daily appearance.

I've found Graph Land useful. I'm publishing it so others can use it too. The whole thing is licensed under the Apache 2 license, so feel free to reuse it in other projects.

Appendix A

A collection of examples, most of which may be useful to game programmers:

A) y = x % 3
B) y = x - 3 * Math.floor(x/3)
C) y = Math.floor(x- 3 * Math.floor(x/3))

Javascript's % operator (A) behaves like C not like Python, which always frustrates me when x is negative. I usually end up using (B) instead. Rounding down (C) gives a formula that converts any value of x to a valid index into an array of length 3.

D) y = 1/(1 + Math.pow(2, -x))
E) y = 1/(1 + Math.pow(1000, -x))
F) y = x<0 ? 0 : x>1 ? 1 : 3*x*x - 2*x*x*x

Smooth transitions can be down with a modified logistic function (D), which is very easy to tweak ((A) gives a slow transition, (E) is much more abrupt). A much faster but less flexible approach is 3x^2-2x^3 (F).

G) y = Math.floor(x) % 2 == 0 ? 0 : 1
H) y = Math.floor(x) % 4 == 0 ? 0 : 1

Sometimes you want abrupt transitions, not smooth transitions. (G) and (H) will give you those.

Appendix B

Convincing random terrain is largely a matter of mixing several frequencies together.

If you use your imagination, you can pretend this is a hill even though it is too smooth:
y = Math.sin(x/4)

Adding in another higher-frequency, lower-amplitude sine wave makes a subtle improvement:
y = Math.sin(x/4) + Math.sin(x/2+17)/2

(The "+17" bit offsets the second sine wave so both waves don't cross (0, 0) together.)

If you keep adding in higher-frequency, lower-amplitude waves you can see the hill gets more and more detail:

1 wave: Math.sin(x/4)
2 waves: Math.sin(x/4) + Math.sin(x/2+17)/2
3 waves: Math.sin(x/4) + Math.sin(x/2+17)/2 + Math.sin(x+19)/4
4 waves: Math.sin(x/4) + Math.sin(x/2+17)/2 + Math.sin(x+19)/4 + Math.sin(x*2+23)/8
5 waves: Math.sin(x/4) + Math.sin(x/2+17)/2 + Math.sin(x+19)/4 + Math.sin(x*2+23)/8 + Math.sin(x*4+29)/16
6 waves: Math.sin(x/4) + Math.sin(x/2+17)/2 + Math.sin(x+19)/4 + Math.sin(x*2+23)/8 + Math.sin(x*4+29)/16 + Math.sin(x*8+31)/32
7 waves: Math.sin(x/4) + Math.sin(x/2+17)/2 + Math.sin(x+19)/4 + Math.sin(x*2+23)/8 + Math.sin(x*4+29)/16 + Math.sin(x*8+31)/32 + Math.sin(x*16)/64

The terrain in my flight simulator works the same way except that I use random noise instead of sine waves for the basic input, so instead of combining many layers of sine waves, it is combining many layers of random noise.

How to fold a paper envelope for storing seeds

I like collecting seeds from plants in my garden. I store them in little folded paper packets, with the name of the plant and the date collected written on the outside. There are lots of ways to make envelopes out of paper, but this one is my favorite because it is so simple: