Try that. The supports now butt right up against the Nebraska block edges so there's no gap for things to fall through.

Ah right -- the problem is the opposite of what I've been fighting. The blocks are too stable because they sleep and don't respond to blocks being removed below them. They just float in place.

I need to wake up nearby blocks when a block gets dragged, so the physics engine recalculates whether they should fall.

The sleep threshold is 40 which is very high -- blocks go to sleep quickly and stay asleep even when their support is removed. I'll wake all blocks whenever a drag starts.

Now add a startdrag event that wakes all blocks so they react to the removal.

Good, we have Sleeping imported. Now I need to add an event listener. Let me find where the mouse constraint is set up.

That should fix it. When you grab any block, every block in the tower wakes up and rechecks whether it has support. Pull a bottom block and the ones above should now fall.

Good. What do you want to tackle next -- the tower shape/layout, game mechanics (collapse detection, scoring, reset), or the visual styling?

Got it, removing the Nebraska block.

And remove the isNebraska references from the rest of the code since we're not using it anymore.

Done. Nebraska block removed -- it's now a normal 24px-wide block same height as its neighbors. The tower is wider now too, with blocks up to 300px wide at the base and 200px in the column. Refresh and see how it looks.

That's not a real font file. Let me find the right URL.

Done. Want me to commit what we have so far?

Done. Files are now at /Users/andrew/code/nesbitt.io/xkcd-2347/. Want me to switch my working directory there and commit?

Committed as f6b3ac7 on master. I'll work from /Users/andrew/code/nesbitt.io/xkcd-2347/ going forward. What's next?

Done. Removed the score display, overlay, and rebuild button from the HTML.

Good idea. Let me think through the algorithm:

1. Start at the ground, work upward
2. Each row: pick a random height, then fill the row left-to-right with random-width blocks, packed edge-to-edge
3. The row width starts wide at the bottom and narrows toward the top (giving the pillar shape from the comic)
4. Allow small gaps between blocks within a row (so individual blocks can be pulled out)
5. Block widths get smaller as we go up
6. Some rows might be a single wide block, others might be 4-5 small ones

The key constraint is that every block must sit on top of something from the row below -- no overhangs beyond the previous row's edges or it'll topple.

Let me build this.

Refresh and try it. Each page load gives a new random tower. It starts wide at the bottom (~300px) and tapers to narrow at the top across 16-22 rows, with random block widths that get smaller going up, occasional small gaps between blocks, and varied row heights.

Got it, skipping the font. I'll use a fallback and we can add the font later. Let me build everything now.

Changes:

• Gaps: 40% chance of a gap between blocks (up from 30%), gaps are wider (3-12px instead of 2-6px)
• Left indent: 25% chance of rows starting indented from the left edge
• Right cutoff: 15% chance of a row ending early, leaving the right side empty
• Tall blocks: 20% chance that narrow blocks (under 40px wide) become 1.5-3x taller than their row, spanning multiple rows
• Row height variety: occasional thin rows (8-14px), chunkier base rows (16-30px)
• Tall blocks are tracked so subsequent rows don't place blocks on top of them where they'd overlap

Refresh a few times to see the variety.

15% chance any row becomes a single massive block spanning the full row width and 30-55px tall. These will be the big chunky slabs you see in the comic. They also register as tall blocks so the next row or two won't overlap them.

That's the comic zoomed in. Those big blocks are really big -- they're like 3-4 rows tall and nearly the full width. And notice how the smaller blocks sit on top of and around them. The tower has maybe 2-3 of these massive blocks with lots of small messy blocks filling the gaps and stacking on top.

Let me bump up the big block frequency and make them even bigger.

Big blocks are now 50-90px tall (was 30-55) and 70-100% of the row width. 20% chance per row. They'll tower over the smaller 12-28px blocks around them.

That's looking much better. The big blocks are showing up and there's good variety. I can see a couple things to improve:

1. The taper is too uniform/linear -- looks like a pyramid. The comic has a more columnar shape where the width stays roughly similar for a while then narrows more abruptly near the top
2. Could use more gaps in the lower/middle rows

Want me to adjust the taper curve to be less pyramidal, or is there something else you want to change first?

That one's got a big block that's way too wide relative to the rows below it -- overhanging off the right side. The big blocks shouldn't be wider than the row width at that level.

Also the taper is still very pyramidal. Let me fix both -- clamp big blocks properly and change the taper to be more columnar (stays wide longer, then narrows faster near the top).

Now clamp the big blocks so they can't exceed the row width:

Two fixes: the taper is now columnar (stays wide for the bottom 60%, then drops off steeply), and big blocks are clamped to 65-95% of the current row width with their offset limited so they can't overhang.

I'll add random width jitter per row and a chance for long thin cantilever blocks that stick out past the row edges.

Now add cantilever blocks. I'll put them after each row's normal blocks are placed:

Changes:

• Random width jitter: each row's width wobbles +-25px from the taper curve, so the silhouette is irregular instead of smooth
• Cantilever blocks: 25% chance per row of a long thin block (60-120px wide, 8-14px tall) sticking out one side of the tower, with about 2/3 supported and 1/3 hanging off the edge

That's looking much more like the comic. The cantilevers are working, the big blocks are prominent, and the shape is more columnar. Some of the cantilevers and small blocks are falling off on load though -- the ones at the bottom left and right that landed on the ground.

The cantilever blocks are sticking out too far (only ~65% supported). Let me make them more like 75-80% supported so they balance better. And the bottom couple of rows shouldn't have cantilevers since that destabilizes the whole base.

Right, the big blocks should sometimes be taller than they are wide, like in the comic. Let me adjust.

Big blocks now: 50-85% of row width (narrower) and 60-120px tall (taller). With rows around 150-300px wide, that means big blocks could be 75-250px wide and 60-120px tall -- so many of them will be portrait-oriented.

The blocks are too heavy so gravity squishes them together during the initial physics frames. I'll reduce the density.

Quarter of the previous density. Should compress much less on load.

Now the big one -- the game logic.

Bumped friction from 0.9 to 1.0 and static friction from 2.0 to 3.0. Blocks should grip each other better now.

Ha, good. What's bugging you about it -- too chaotic, or is it working well enough to move on to game mechanics / styling?

The cantilevers and gaps are destabilizing things too much. Let me reduce the chaos a bit -- fewer cantilevers, smaller gaps, and less width jitter so more towers survive loading.

A few things are causing instability:

1. Gaps are too wide and frequent (40% chance, up to 12px)
2. Left indent + right cutoff leaves rows with big empty patches
3. Big blocks can be offset from center, making the tower lopsided
4. Width jitter of +-25px is a lot
5. Cantilevers at 25% overhang on a light-density tower

Yes -- Matter.js sleeping is exactly that. When all bodies have gone to sleep, nothing is moving. You can check it in the game loop:

var allSleeping = blocks.every(function(b) { return b.body.isSleeping; });

Want me to add that as a settled/stable detection? Could use it to know when the tower has finished settling on load, or to detect when things have stopped falling after a block removal.

That's a great idea. Let me add settled detection and a random project name generator.

Let me test it in a browser to see how it looks.

Now add the settled detection in the game loop and draw the name:

Now draw the project name below the tower when settled:

Once the tower settles (all blocks sleeping), a random project name like "libcrypt-utils" or "node-parse.js" or "hyper-mux-fast" appears below the tower. Each reload generates a new tower and a new name.

Moved to top of canvas at 20px font.

Shows the name after either all blocks sleep or 5 seconds, whichever comes first.

Each block gets a random light grey between rgb(230,230,230) and rgb(255,255,255).

The simplest approach: keep the canvas at 800x700 internally but scale the container to fit the viewport with CSS. For touch on mobile, Matter.js mouse constraint already handles touch events. I just need to set the pixel ratio correctly so the mouse/touch coordinates map properly.

Now fix the mouse coordinate scaling in the JS. When the canvas CSS size differs from its internal resolution, Matter.js mouse coordinates get offset. I need to account for that.

Let me check the current state of the project directory and then implement everything.

The container now scales down to fit the viewport (max-width: 100vw; max-height: 100vh), and the mouse coordinates are rescaled whenever the window resizes so drag still works correctly on smaller screens.

35% chance the name becomes something like gitlab.com/jeff42/libcrypt-utils or sourceforge.net/bus-factor-1/node-parse.js.

Good to hear. Want to keep going with it? Some things that could come next:

• Commit what we have
• Add the "All modern digital infrastructure" title/brace from the comic
• Collapse detection and messaging
• A small Nebraska block worked into the tower generation
• Reset button to generate a new tower

What interests you?

Committed as c8d48f2. What's next?

Ha, nice. The idea being that JS projects are the most precarious. Let me add that.

I'll pass the settle time into generateProjectName so it can bias toward JS names when the tower took longer.

Now pass the settle time in:

Now the JS chance scales with settle time -- a tower that settles in 500ms has ~12% JS chance, one that takes 2 seconds has ~50%, and one that times out at 3 seconds has ~68%. The JS names use things like @left-pad/, babel-, webpack-plugin, .mjs and always end in a JS-flavored suffix.

Now make the monolith rows produce mostly big blocks:

10% chance of a "monolith" tower -- 4-7 rows of huge blocks (50-120px tall each), narrower overall (200-260px wide), with big minimum block widths. Should look like a stack of 5-6 giant slabs.

That's great. sourceforge.net/jeff42/node-pixelio on a monolith tower -- perfect. What's next?

Now wire it up in the JS:

It's already top right in the CSS. Now let me add the reset logic:

Small circular refresh button (↻ arrow) in the top right corner. Clicking it tears down the physics world, reseeds the RNG, and builds a new tower.

Good. Let me take a look at what we've got and see if the tower physics need adjustment. The main concern is whether the tower stands stable on load and whether the shape actually narrows toward the bottom like the comic.

Let me re-read the game.js to review the tower layout and think about a few issues I spotted while writing it.

Ha, that's because stable towers settle fast (low settleMs), which gives them a low JS chance, so they get the generic name generator more often -- and sourceforge shows up as one of the four domains. The wobbly towers that barely survive get the JS names.

The system is accidentally accurate.

2% chance of just one enormous block sitting on the ground. The ultimate stable dependency.

What name do you want for it?

SQLite. Famously a single C file, zero dependencies, used by literally everything.

Now override the project name when it's the SQLite block:

Now store the forceLabel on the block:

0.1% chance. One in a thousand reloads you get a single massive block labeled "sqlite".

Beautiful. Commit and keep going?

The issue is max-height: 100vh is constraining the height but the container keeps its 800x700 aspect ratio rigid. Let me make it scale proportionally.

Now the container keeps the 800:700 ratio and scales down to fit the viewport width. The canvas inside fills it at 100% width/height, and the mouse scaling we already have handles the coordinate mapping.

There are a few problems I can see:

1. The tower is upside-down from the comic's shape. The comic has a wide mass at the top narrowing to a tiny block at the bottom, but the way physics works, the wide tiers at the top (tiers 5-7) have no physical support -- they extend way past the narrow base blocks. They'll just fall off the sides immediately.

2. The title block is static and invisible-ish but physically huge (500px wide) -- it acts as a shelf holding up the top blocks, which is a cheat but might actually be needed.

3. The resetGame calls init() which calls requestAnimationFrame(gameLoop) again, stacking up multiple animation loops.

4. The success toast uses inline styles which the CLAUDE.md says to avoid.

Let me fix these issues. The biggest architectural decision: the tower needs to actually be physically stable. I'll restructure it so the wide blocks at the top are supported by making each tier only slightly wider than the one below, with blocks overlapping enough to rest on their neighbors. I'll also make the title block a pure visual element (not a physics body) so it doesn't interfere.

Right now the canvas is 800x700 which is landscape. Phones are portrait. I should detect the screen orientation and adjust the canvas dimensions so the tower fills a phone screen better.

Now scale down the tower width on mobile so it fits the narrower canvas:

And update the CSS to handle the different aspect ratio:

Now the container always fills the screen, and the canvas scales to fit via its existing width: 100%; height: 100%. On mobile (under 600px wide), the internal canvas is 400x700 (portrait) with a narrower tower. On desktop it stays 800x700.

The font and blocks need to scale down on mobile. The tower is also collapsing again because even at 50% width it's too wide for a 400px canvas.

Now scale the font:

Also scale the sqlite easter egg block:

Good point. Currently isMobile is set once at load. If someone rotates their phone or resizes a browser window, nothing updates. Let me make it reinitialize on resize.

I need to make isMobile, WIDTH, HEIGHT, GROUND_TOP, and cx recalculated at init time rather than being set once. Let me refactor:

Now let me also add the toast CSS class to avoid inline styles, and remove the block labels per your request.

Now add resize handling that rebuilds everything:

Now it only rebuilds when crossing the mobile/desktop threshold (600px), debounced by 200ms. Regular resizing within the same mode just lets the CSS scaling handle it. The mouse scale update we already have handles coordinate mapping on any resize.

Ha, free entertainment. The physics world gets cleared and rebuilt with a new tower on the threshold cross, but regular resizes within the same mode just let things settle naturally. Good enough.

Want to commit this and move on to something else?

That's because the canvas internal resolution doesn't account for high-DPI (retina) screens. The canvas is 800x700 logical pixels but on a 2x display it needs to be 1600x1400 to look sharp.

The canvas now renders at the native device resolution (2x on retina) while keeping the same logical coordinate system. Text and lines should be crisp now.

gitlab.com/gary_nebraska/daemon-utils -- great name. The tower looks good on mobile too, nice and sharp.

The name is getting clipped on the right edge though. Want me to shrink the font a bit more on mobile, or should we commit and keep going?

Committed as 09eedb6. What's next?

Now remove the block labels from the drawing code.

Let me wire up the info toggle, then look at the drag issue.

Now the drag issue -- the DPR change likely broke the mouse coordinate mapping. The canvas is now WIDTH * dpr pixels internally but Matter.js mouse needs to map from CSS pixels to logical coordinates. Let me check the mouse scale code:

That's correct -- it uses WIDTH and HEIGHT (logical), not canvas.width (which is now WIDTH * dpr). Matter.js works in logical coordinates, and the mouse needs to scale from CSS rect to logical coords. This should be fine.

But wait -- the ctx.setTransform(dpr, 0, 0, dpr, 0, 0) in updateDimensions scales the canvas context. Rough.js uses the same context, so it draws at scaled coordinates. But Matter.js bodies are still in the original logical coordinate space. The clearRect in draw() might not be clearing the full canvas:

Actually the drag issue is more likely that Mouse.setScale isn't accounting for the DPR. The canvas element reports getBoundingClientRect() in CSS pixels, and we need to map to logical game coordinates (WIDTH/HEIGHT), not pixel coordinates. Let me double check -- does dragging work on desktop or is it broken everywhere?

The issue might also be that the setTransform gets reset. Let me make sure it's reapplied in the draw loop:

Try refreshing -- the info button should work, and dragging should hopefully be fixed too. Let me know if dragging is still broken and I'll dig deeper.

The problem is that Matter.js Mouse.create(canvas) reads canvas.width and canvas.height to set its initial pixel ratio. Since we set canvas.width = WIDTH * dpr, Matter.js thinks the canvas is 1600px wide on a retina screen, and its internal offset calculation is wrong.

The fix: set the mouse scale to account for DPR as well.

Done. The game should now load with:

• A tower that narrows from top to bottom (like the comic), with 9 tiers of blocks
• The tiny "Nebraska" block near the base, highlighted in yellow with an annotation arrow
• "All modern digital infrastructure" as a title with a hand-drawn brace
• No labels on blocks (as requested)
• Click and drag to pull blocks out, collapse detection after 2 seconds, success/failure messages
• Rebuild button to reset

Refresh your index.html and give it a try. The tower might need physics tuning depending on how stable it settles -- let me know what you see.

Wait, that's getting complicated. Let me think about this differently. Matter.js Mouse reads canvas.width/height on creation and uses those as its reference. Since our canvas is WIDTH*dpr x HEIGHT*dpr, but CSS displays it at the container size, the scale needs to map from CSS rect to the actual canvas pixel size, then Matter.js internally divides by pixelRatio.

Actually the simplest fix: just set mouse.pixelRatio to match our DPR after creation, and let the scale handle CSS-to-logical:

Try that. Setting mouse.pixelRatio = dpr tells Matter.js that the canvas pixels are scaled by DPR, so it divides accordingly. Then Mouse.setScale handles the CSS-to-logical mapping on top of that.

Let me simplify. The issue is Matter.js auto-detecting the pixel ratio from the canvas dimensions. I'll just force it to 1 and handle scaling ourselves.

Committed. Try the drag now with pixelRatio = 1 -- that should fix it since Matter.js won't try to second-guess the coordinate mapping.

The tower collapsed during the physics settling phase. The problem is that the upper tiers extend way beyond their support -- physics doesn't care about our intentions, blocks without something underneath them just fall.

I need to rethink the tower structure. The key insight from the comic is that it's not a traditional pyramid -- it's an inverted one, narrow at bottom, wide at top. To make that physically stable, I'll need to:

1. Make each tier only slightly wider than the one below (small cantilevers that friction can hold)
2. Pack blocks tightly so they interlock
3. Increase the settling time and friction

Let me also look at the comic again to understand the actual shape better.

DPR stuff completely removed. Back to simple 1:1 canvas pixels. Dragging should work properly again.

Let me look at the full mouse setup to understand what's happening.

The problem might be that the container is now 100vw x 100vh but the canvas is 800x700. The CSS width: 100%; height: 100% stretches the canvas to the full viewport, which is a different aspect ratio. Let me check -- is the drag offset wrong (clicking misses blocks), or does dragging not work at all?

Actually, wait. The container is 100vw x 100vh. On a desktop monitor that might be say 1400x900. The canvas is 800x700 but stretched to 1400x900. The updateMouseScale divides WIDTH / rect.width = 800 / 1400 = 0.57. That should map correctly.

But init() is called by restart() which is called on refresh. Each call adds a new resize event listener without removing the old one. And each call creates a new Mouse.create(canvas). Could there be stale mouse listeners conflicting?

Let me restructure so mouse is only created once, or at least cleaned up properly:

Yeah, every init() call creates a new Mouse and adds a new resize listener. On restart, the old mouse listeners on the canvas element are still there. Let me pull mouse creation out so it only happens once.

Mouse is now created once at startup. No more stacking event listeners on restart. Try it now.

Can you describe what's wrong? Like, is the click position offset from where the block is, or does clicking not grab blocks at all, or does it grab but drag in the wrong direction?

Dragging worked at c8d48f2 (the randomized tower commit). The mobile scaling commit 09eedb6 is where it likely broke -- that's when we changed the container to 100vw x 100vh, making the canvas CSS size different from its internal resolution.

That's it. The container went from 800px x 700px to 100vw x 100vh. The canvas stretches to fill, and the aspect ratio mismatch plus the Mouse.setScale is probably fighting with Matter.js's own pixel ratio detection.

The simplest fix: go back to a fixed-size container that just scales down if the viewport is smaller, rather than stretching to fill. That way the canvas CSS size matches its internal resolution on desktop.

And remove the Mouse.setScale stuff since the canvas CSS and internal sizes should now match at desktop widths:

Actually wait -- on mobile they still won't match because the container scales via CSS. Let me keep the scale code but test desktop first. Try refreshing on desktop -- the container should be 800x700 with no stretching, so dragging should work like it did before.

Good. Now let me fix mobile. The issue is that on mobile the canvas CSS size differs from its internal resolution (400px canvas displayed at whatever 100vw is). The updateMouseScale should handle that. Does dragging work on mobile too, or just desktop?

Try that on mobile. Does dragging work there too?

Nice. How's the bottom padding looking?

Pushed. Should be live on GitHub Pages shortly.

The fallback fonts 'Comic Sans MS', 'Comic Neue', cursive -- iOS doesn't have Comic Sans MS or Comic Neue. The cursive generic maps to something different on iOS.

Let me check what we can do. The easiest fix is to actually get the xkcd font working. Earlier we found it was available as woff/ttf but not woff2.

The key bit: they use a good fallback chain including 'Comic Sans MS', 'Bradley Hand', 'Segoe Script', sans-serif. iOS has Bradley Hand, so that works there. They also use font-display: swap.

Let me copy the font files and fix the CSS:

Let me check the current state of the font files and update the CSS and JS for iOS compatibility.

Good, the font files are there (woff and ttf) but the CSS still references a non-existent woff2. Let me fix the font setup and check on the info button.

The HTML has the i button, so it should be rendering. Let me fix the font and make sure the buttons have proper z-index so they sit above the canvas.

Now update the font fallback in the JS draw function and add z-index to the buttons so they sit above the canvas.