Signal

Signal is a puzzle about building the shortest possible message using variable-length codes. Each letter in the message appears a certain number of times, and you decide how many bits its code word gets. Short codes are scarce: giving one letter a one-bit code spends half of your entire budget. The challenge is to spend that limited shortness on the letters that appear most often, while making sure the rare letters still fit within the ceiling. The puzzle is built on a real piece of information theory, and the code it builds is a real working code.

What the puzzle asks you to do

A message needs to travel down a wire as a stream of bits with no gaps between the letters. Each letter has a count showing how many times it appears. You set the code-word length for each letter using small plus and minus buttons. The total number of bits in the message is the sum of each letter's count multiplied by its code length. Your goal is to make that total as small as possible.

There is a hard constraint. The codes must be prefix-free, meaning no letter's code can be the start of another letter's code. If the letter E is coded as 0, then nothing else can start with 0, because the receiver would never know whether a 0 meant E or the beginning of something longer. The bar at the bottom of the screen shows how much of your shortness budget you have spent, and if it overflows, no valid code exists at all.

Controls and how to adjust lengths

Each letter sits on its own row. You see the letter, its count, a pair of buttons to increase or decrease the code length, the current length as a bold number, and the actual bit pattern the code would use. The cost in bits for that letter appears at the end of the row.

Press the minus button to make a code shorter. Press the plus button to make it longer. Neither button will go below one bit or above the ceiling. After every change, the bar updates to show your new budget usage, and the bit patterns regenerate to show the actual code words. The message total updates in the stats panel so you can see whether your change helped or hurt.

The game starts every letter at the same length, a flat code where all letters cost the same number of bits. That is always beatable, because a flat code wastes bits on rare letters that could be given to common ones.

Scoring and the change budget

Your score is the number of changes you make to reach the optimal total. The game knows the true best, because it tries every possible set of lengths within the ceiling and picks the one with the fewest bits. You win when your message total matches that best. You have a limited number of changes, shown in the stats panel, and running out before reaching the optimal code ends the round.

The best score across sessions is the fewest changes needed to reach the optimum. It is stored in your browser and never sent anywhere. Lower is better, and a player who reads the letter counts carefully before pressing anything will need fewer adjustments than one who adjusts by trial and error.

Difficulty levels and what changes between them

The Alphabet selector offers three sizes. Small gives you four letters with a ceiling of three bits. Medium uses five letters and the same ceiling. Large uses six letters and raises the ceiling to four bits. More letters and a higher ceiling both increase the number of possible length combinations, making it harder to find the optimum by guessing.

At every level the letter counts are deliberately lopsided. One or two letters appear many times while the rest trail off sharply. That imbalance is what makes the code useful: if every letter appeared equally often, the flat starting code would already be optimal and there would be no puzzle at all.

Strategy: give the shortest codes to the most common letters

The core insight is that a one-bit code saves one bit every time that letter appears. A letter that appears forty times saves forty bits if you can shorten it by one bit. A letter that appears three times saves only three bits for the same change. So the common letters should always get the shortest codes, even though that forces the rare letters to be longer.

Look at the counts first, before touching any buttons. Sort them in your head from most common to least common. The most common letter should get the shortest code, the second most common should get the next shortest, and so on. If two letters have the same count, it does not matter which one gets the shorter code, because the total will be the same either way.

Strategy: understanding the budget bar

The bar is not just a warning light. It is a direct representation of a mathematical rule called the Kraft inequality. Each code length costs a fraction of the total budget: a one-bit code costs half, a two-bit code costs a quarter, a three-bit code costs an eighth, and so on. Each additional bit halves the cost. The bar fills up as you add these fractions together, and a valid prefix-free code exists exactly when the total is at most one.

A nearly full bar is usually a good sign. Leaving budget unspent almost always means some letter could be shortened by one bit for free. The optimal code typically uses the entire budget or comes very close. If you see slack in the bar and one letter is longer than it needs to be, try shortening it. If the bar stays within bounds, you just saved bits for nothing.

Common mistakes and how to fix them

The most frequent mistake is shortening a rare letter instead of a common one. Saving one bit on a letter that appears twice saves two bits. Saving that same bit on a letter that appears thirty times saves thirty. Always check the counts before deciding where to spend your budget.

Another common error is making all the codes the same length. Equal lengths are never optimal when the counts differ, because you are paying the same cost for a letter that appears once as for a letter that appears fifty times. The flat code is the starting point, not the answer.

Overflowing the bar is the third mistake. When the bar goes red, no valid code exists and the message total shows a dash instead of a number. The fix is always to lengthen something, and the cheapest thing to lengthen is the letter that appears least. Every bit you add to a rare letter frees up budget that can be spent on a common one.

The real theory behind the puzzle

The constraint in this game is called the Kraft inequality, written down by Leon Kraft in 1949. It says that a prefix-free code with lengths L1, L2 and so on exists if and only if the sum of two to the negative power of each length is at most one. The bar is that sum, and the game builds the actual canonical code whenever the bar fits. The bit patterns shown beside each letter are a real working code: no code word is the start of any other.

Finding the optimal set of lengths for a given set of frequencies is exactly what Huffman coding does. The game's search tries every combination rather than using the Huffman algorithm, but the answer is the same. The connection to real-world compression is direct: formats from ZIP archives to JPEG images use codes chosen by this principle.

Privacy and how the game runs

The entire puzzle runs inside your browser tab. Nothing is uploaded, there is no account, and your best score stays in local storage on this device. Once the page has loaded it works offline, so you can work through coding puzzles with no connection at all. The exhaustive search over all possible length sets happens on your own processor in a fraction of a second, because the number of combinations at these sizes is small enough to check completely. The canonical code generation and the budget calculation are also done locally.