Traffic engineers model this with the BPR equation, which models how real accumulated traffic grows at a quadratic rate relative to capacity.

If the bottleneck were to suddenly clear, the road downstream can now discharge at full capacity, but cars are still arriving from upstream at some rate. The queue only shrinks at the difference between what can now get through and what’s still piling in: the drain rate is capacity minus activity, not just capacity.

So the clearance time depends on how close arrivals still are to capacity. If the road is still busy—say arrivals are at 90% of capacity—the queue drains at only 10% of capacity, which means it takes roughly nine times longer to dissipate than it took to form at the same demand. A jam that built over 20 minutes can take a couple of hours to fully unwind if traffic stays heavy.

This is theoretically realistic—except, of course, for the part where a road instantaneously increases capacity. That’s something unique to a computer system overseen by a human player. And that human player craves instant feedback, making the crawling unwind of blocked traffic a real disadvantage in gameplay experience.

This has informed one of Throughput’s critical design deviations from other modern citybuilders. Because its representation is pure abstraction—there’s no individual car with a physical place along its route—Throughput’s system can be highly responsive to changes.

The pathfinding in Throughput moves as fast as your machine. Critical matching is kicked off near the 4-bar boundary (with predictive heuristics on how long it will take to complete), but the rest is optimized as much as possible in between each tick.

As it sands now, however, in a city that spans the entire map, we still might see only 20% or so optimize at a time. While still highly dynamic, I wanted more headroom to add depth.

Throughput was built entirely using gdscript, Godot engine’s special scripting language. All programmers acknowledge scripting languages are notoriously slow, but in a way where we make a sage comment about it and move on, since the benefits in architecture flexibility usually outweigh the costs.

With algorithmically heavy workloads though, the application starts to run into real performance bottlenecks. In this case, converting to using C++ and creating native architecture builds is one of the strongest tools in the toolbox.

Making the choice to use C++ means that I’ll have to compile each build separately on a real machine of each type—windows, mac, and linux. Not so bad to do once, but incredibly painful to do constantly.

Therefore, the sharpest approach is the hybrid one—algorithmic optimization goes into a C++ “core.” This allows me to solidify a steady state for what C++ is good at, and I keep flexible gdscript for painting and UI—what it’s good at.

I’ll show you how to determine when making this structural tradeoff is worth it—for any language pair.

When building this sort of cross-language architecture, the boundary between languages is the main thing to worry about. We have to worry about the cost of marshaling: porting data from one language’s structure to another.

There’s one context in which the word “marshaling” is very familiar: parsing json into Golang. Converting json into Go data structures is the biggest reason why choosing Go “because it’s faster” is often the wrong path.

Parsing data into another data structure is typically linear. Therefore, in order to make up for a language swap, you usually look for whether the compute operations scale superlinearly.

With webservers this often isn’t the case; the majority of requests are handoff to the database. This is why in performance for frontline servers, Node.js can be the choice that wins: while in Golang you’d be paying cumbersome cost to marshal json per request, json is quite familiar to Node.

This method is how we can also examine the tradeoff with gdscript and C++, albeit with slightly different constants: Conversion is more intensive, but the payoff in compute speed is an order of magnitude larger.

While the theoretical payoff in this case is much more clearly tempting, the case where data is constantly moving across the linguistic boundary a huge potential failure mode. Luckily for this traffic sim, matching and optimization are pretty well isolated—they’re already threaded.

And the payoff is visibly real. On a city that spans the entire map, it can now optimize every link 12x over. To really get a feel for this, you’ll get to try it yourself: I’ll soon be releasing a public branch on Steam with the C++ core. You’ll get to see just how quickly the map changes—and tell me if it actually feels too responsive.

There’s a lot I can potentially do next with all this extra computational space this architecture buys me. That’s the real beauty in what good performance architecture does: it expands our possibilities.

The system that undergirds Throughput is a time-tested one: based on the continuous economic system first introduced by SimCity. Residential population creates demand for Commercial, which in order to have goods to supply, creates demand for Industrial. This core gameplay loop works so well that it became the foundation of a whole genre.

When I first developed the system that undergirds Throughput, I created similar requirements for these zones in a 1:1:1 ratio: one resident requires one good, one good requires one unit of freight, and one unit of freight requires one worker.

You can imagine this quickly devolved into a degenerate strategy: small atomic clusters of zones could be placed in a repeated alternating tile pattern for perfect satisfaction—not very interesting.

I had to go back and look at what the ratio looked like in SimCity 4. Simple enough to observe—at least at low densities—the demand for Residential zones far outpaced the demand for Industrial.

So I decided to tweak the ratios. Once again emphasizing the power of a tunable system for defining zone supply and demand, I arrived at these levels:

• ADULT (Residential): produces 1 ADULT, needs 1 GOOD → column ADULT: 1 GOOD.

• GOOD (Commercial): produces 3 GOOD, needs 1 ADULT + 1 FREIGHT → per unit GOOD: ⅓ ADULT, ⅓ FREIGHT. (the ⅓s come from dividing by the batch size of 3.)

• FREIGHT (Industrial): produces 1 FREIGHT, needs 3 ADULT → column FREIGHT: 3 ADULT.

The most important aspect being 1 freight requiring 3 adults.

Empirically, this works. The system demands it grow constantly to be viable, and I’ve watched multiple smart people attempt to develop a degenerate strategy for it to no avail. But can we prove that it works?

One nice thing about human-designed systems: they can be exact fits to what humans conceived of for real-world abstraction—the map is the territory.

And there’s one particular abstraction from macroeconomics that fits perfectly here: a Leontief-style input-output model.

The Hawkins-Simon condition comes from a 1949 Econometrica paper titled "Some Conditions of Macroeconomic Stability." It “guarantees the existence of a non-negative output vector that solves the equilibrium relation in the input–output model where demand equals supply.”

In other words, Hawkins-Simon checks whether a system is “productive:” that every part of the output vector is greater than 0 means that there is only positive output from the system, and nothing is at a deficit.

On the flip side, this means that if any of the parts is less than zero, then the system runs at a deficit. The boundary where the determinant equals zero—the 1:1:1 ratio I mentioned before—describes a degenerate matrix.

Geometrically a determinant is the volume-scaling factor of a linear map. I − A maps gross output → net-output-available. So det(I − A) measures how much net surplus the entire web output per unit of gross activity, as one number.

By looking at the leading principal minors—the determinant of each submatrix—we can determine exactly where this system begins to tip negative.

Leading principal minors of I − A:

• 1st (Adult alone): 1 ✓

• 2nd (Adult + Good): 1 − 1/3 = 2/3 ✓

• 3rd (full system): expanding, det(I − A) = 1 − 1/3 − 1 = −1/3 ✗

The Hawkins-Simon condition is failed at the third minor. The residential/commercial pair would be a viable economy on its own if freight were free. The 3-workers-per-freight cost is where the deficit enters the web.

What we’ve found in the principal minors can be further described by the spectral radius: the characteristic polynomial is λ³ − λ/3 − 1 = 0, whose real root is 1.11.

What the spectral radius tells us is ultimately simple to express: each unit of final consumption demands ~1.11 units of upstream production, compounding ~11% per propagation round. The system fails viability, but barely. Decay is the default, but it’s a slow leak, not a rupture.

The only source of viability in this system is the one thing outside the matrix: the player. Every action is an injection the economy can't generate alone. Mierle Laderman Ukeles called this maintenance art; the work of keeping the system alive is in itself the work.

There’s a certain point at which systems thinking must feed back into systems feeling.

As I was tuning my Degenerate state's pruning of unmatched cells, I looked to sharpen the cut between it and Euphoric, which is a Throughput-induced spurt of unchecked growth. Euphoric and Degeneration name the two open half-spaces, and the uninhabitable degenerate point sits unnamed between them as the threshold you're always crossing.

Degeneration can be difficult to keep up with. When Euphoric mode is reached (and finally disables pruning) I’m like, "phew, I can take a breath for all of two seconds."

Euphoric isn't a reward state, but a release state. Typically only the former is emphasized in game design. But reward states are flat dopamine; you did the thing, here's the cookie.

Release states require prior tension. They're earned by surviving pressure. The difference matters because reward states get less satisfying with repetition (tolerance builds, the cookie gets smaller), while release states stay satisfying as long as the tension is real (because each tension is its own arc).

Spectral radius = 1.00 is subsistence, spectral radius = 1.67 would be freefall, spectral radius = 1.11 is a game.

Soon you’ll be able to feel this for yourself, as the demo launch is imminent. Build your city. Watch it breathe.

Throughput is a city builder game: simulated people have homes, they go to work, they buy things. I wanted to make the simulation as dynamic as possible—if someone found a job with a shorter commute, I want them to take it!

This means it’s a gigantic pathfinding network flow problem—and it was beginning to have some problems. On “large” games, I was already starting to see visible simulation slowdown.

The visibility and interaction slowdown I mitigated via threading and by holding copies of the simulation while the thread completes. Still, Throughput is a game in time with music, and I intend for simulation refreshes to be snappy—it’s an intuitive feel problem if it isn’t. And I knew I wanted my games to get 10x larger.

The work I did threading the simulation built a solid foundation of feature-specific tests via automating Test Driven Development. Crucially, I also created save games that I then use as benchmarked test fixtures. These guardrails are the “plan to be stupid” I made right before I blindly tell Claude to optimize against the benchmark.

The core of our simulation uses Dijkstra’s pathfinding algorithm. Most of our calls are multi-target, so we don’t go for A*. Ironically, this is where the first 36x optimization came from: removing early-termination that would make sense for the single-target case.

Dijkstra from a single source is already naturally a multi-target algorithm. If you let it run, the first time it pops node X is the moment it knows the cost-min distance from source to X. That's true for every node, simultaneously, from one expansion.

The rest of it? Depth pruning: We don’t need to expand paths that are already worse than the current one.

But the actual how is just the artifact of how I found it. Everything is ultimately a search problem: if there’s something you want to achieve, there exists a path to get you there. Search is the act of finding it—so execution of your strategy rests on your search tactics.

In this case we employ a particular tactic for working with black box systems: you look at your inputs and outputs. I knew my inputs (test fixture), and I had the expected outputs (unit tests, benchmarking).

It’s often repeated that you should “be specific” when talking to computers, but it’s important to examine what that actually means. A figure takes shape only via its negative space—being specific is as much about what you don’t require as much as it is about what you do. That flexibility is what makes room for what you care about.

It’s fine that the first implementation wasn’t optimal—it did what it needed to until it didn’t. That’s what iteration is for. In fact, at its core O(VlogV) Dijkstra still shows pretty uncontained growth; now that the truly naïve implementations are fixed, we’re going to have more specific tradeoffs to make.

I did not want to deal with copying my drive over with dd (a.k.a. the data destroyer) or any of the random third-party software with which you’re expected to port Windows to a new drive. Or with Windows license keys. Or with Windows.

Lately, I’m not the only one. The negative sentiment against Windows (and other Microsoft software) has reached a cultural breaking point: the most memorable quote from the Artemis II flight (to the moon!) was “I have two versions of outlook and neither are working.”

But simply annoying your users isn’t enough. Companies often conclude that their user annoyance is worth the tradeoff, because they don’t immediately see any real effects on user engagement or churn. This works so long as the company’s moat remains intact: without the presence of a viable alternative, you can pretty much perpetually mask dissatisfaction—that is, until the dam breaks.

Enter SteamOS. It’s entirely possible—thanks to the efforts of Valve (the creators of Steam, and more importantly, the version of Linux they created for their Steam Deck)—that Microsoft may lose its positioning.

They’re a big reason why many of my favorite games have native Linux builds, that many say run better than on Windows. But even more wildly, Steam’s version of WINE compatibility layer, Proton, actually works.

My gaming machine began its new life as a Linux Mint machine thanks to Proton. This allows me to run even Windows builds, even for graphically intensive games like Cyberpunk 2077—the type most historically dependent on Windows scaffolding. There goes Microsoft’s moat.

At least a big chunk of it. This win will need to generalize to more diverse types of software. This is a lot more viable than it might initially seem—in fact, it’s the biggest success story of the decade: the chips NVIDIA developed for gaming ended up as the backbone of AI.

I had originally played Cyberpunk 2077 on the Switch 2—the main reason I brought Cyberpunk 2077 to Steam was to try to mod it. But it wasn’t just the game itself I needed to run—I would also need it mod utility WolvenKit, a non-Steam Windows program. It was WolvenKit that clued me into my most recent experiment.

You see, there was one more Windows program I found myself rebooting for (on the occasion I’m not simply being a degenerate gamer): Ableton Live—a digital audio workstation meant for music production.

I decided to try running Ableton the same way I ran WolvenKit—quote via the Linux instructions:

Now here's where it gets weird, open Steam and go to your library. Find the "Games" tab on the menu bar, and click on "Add a Non-Steam Game to My Library"

I apply this technique to the Ableton executable, and voila! I can run it using the Proton compatibility layer.

That said, getting low-latency audio drivers to work will be a different story—it’s still not as good as a Mac’s Core Audio, which astoundingly is low-latency out of the box. Linux has more annoying solutions for this, and so does Windows—and it’ll be a combination of getting both to work to get them within the compatibility layer.

Apple wins by a landslide in this regard because they were building Garage Band and Pro Tools, and wanted to make them great. (Now, if only it could work on custom hardware…)

The Proton development story is practically a page right out of Apple’s playbook. They have a specific use case in mind that they intend to make flawless through every part of the stack—including vertical integration via hardware.

What’s often ignored is how well this strategy ends up generalizing. Great support for Pro Tools means great support for Ableton. Great support for SteamOS means great support for Linux. A great whole is the sum of great parts.

Valve is experimenting with a sweet spot, blending what worked about the Apple strategy with filling the decentralized customization gaps previously patched by Windows. Look at it from a slightly different angle, and you find they’re actually doubling down—on the “great parts” method.

That’s a remarkable way to dig away at Microsoft’s moat—until suddenly, the moat’s drained entirely.

And genre is an intimidating topic to talk about. On the one hand it can bring out the most rigid and persnickety in us, such that on the other hand it almost seems necessary to throw up our hands and deem it reductive. But failure to describe begets failure to have the thought entirely, so is not outright anti-intellectual to reject categorization—reject naming things?

Unfortunately for you all I’m an Engineer, so I reduce intellectualism to practicality. And there’s two primary benefits I see to pushing forward on conversations about genre:

• Discerning what makes a piece work. As an artist, it’s useful to deconstruct and seek commonalities. It’s the equivalent of taking apart an electronic device to see how it works and putting it back together again.

• Distinguishing relevance and legibility: there’s such a thing as a piece that is too original. While an artist may have esoteric ideas, a piece of work that is too far removed from existing work is doomed never to be understood—even by the artist, the art forever stuck as a vague idea.

As an exploratory example, let’s examine the path to possibly one of the most acoustically gobsmacking moment in music history: the journey of the artist Sonny Moore, a.k.a. Skrillex. His debut EP Scary Monsters and Nice Sprites (as the name suggests, a love letter to the call-and-response composition method) was explosive material back in 2010. It was a total maximalist subversion of Dubstep, a surprisingly minimal genre at its core. So much so, that “UK Dubstep” and “American Dubstep” (or “Brostep”) are now often considered separate genres.

But Moore’s musical journey didn’t begin with the Skrillex project. He had previously done vocals for a “Screamo” band called From First to Last, which combines influences from the Emo and Metal genres. He learned sound design with the influence of Noisia, who primarily worked within the Drum and Bass genre (arguably Brostep’s closest relative).

It’s worth noting the crescendo of Skrillex’s artistic arc didn’t culminate until a year later, when he reached for even more estranged rock influences to create what in my opinion will go down as one of the greatest works of the 21st century: Breakin’ a Sweat, the track he created with The Doors, topped off with an ancient clip of Jim Morrison himself predicting Skrillex’s existence.

There’s a lot of information apparent in this graph alone, and it roughly mirrors the way Jim Morrison is thinking about it—as a progressive branch and merge, an evolution.

American Dubstep was a massive distillation of many genres that came before it. One might expect that to mark the beginnings of a Cambrian explosion—instead, it was more like an extinction event. Its legacy mostly consists of works that, while often good, are nonetheless self-referential.

The best-fitting model to describe what’s happened here is a Thomas Kuhn paradigm shift: wherein a revolutionary idea is born from pushing up against the boundaries of the current ways of thinking—once the revolution happens, we begin again to explore the current New Idea to its fullest potential. I think this ultimately is a good signal for American-style Dubstep: that it feels fully-explored doesn’t mean it’s done with, it means it’s ready for another subversion.

The conclusion itself is perhaps less fascinating than the structures that let us derive it. Structurally, genre information is typically stored as a tag system. A given song is tagged with, e.g. Electronica. There’s circumstances where tag systems are really powerful—it’s often the better way to structure a filesystem when everything is indexable on a pivot. But there’s another way to organize files that has proven incredibly effective for tracking complex, continuously updating work, and that’s git—structured as a Directed Acyclic Graph like the one above.

What about the second use case, distinguishing relevance? Tag systems can do pretty well at recommendation, especially when extended to multi-tag or subcategorical systems. But from the venn diagram illustration below, we can see we easily lose a lot of relevant information to the conversation we just had above.

You’ll notice that, while we can put a good chunk of Skrillex’s influences under the “Electronic” category, we lose all association with his previous Rock-adjacent roots. An American Dubstep enjoyer might very easily get more out of the Metal category than they would out of UK Garage—or anything House-adjacent. In fact, although not officially categorized yet, I think that’s the new paradigm the music of the 2020s is ramping up to explore.

Category graphs an be as granular as necessary—so granular, in fact, that the categorization can be at the level of an individual work. We can define not by the node but its edges—making the categorization so implicit that it practically melts away completely. This is fundamentally different from an outright refusal to categorize: with this—yet another model that ends up subverting what it intended to grasp—we end up with decidedly useful lines of pursuit to aid in understanding our own creation.

• The code built with too many individual features would need a refactor

• Refactoring would introduce more regressions than I could easily test at once

I’d first experienced the former situation building Supply and Demand; certain features that had a lot of commonality were getting more and more one-off data structures and references, and many features were getting dumped into a single file, and it was becoming a lot of context for Claude to read. I wanted to refactor these into an extensible framework, so that I could add features without needing to edit the code at all.

When it came to Galactic Golf, I made sure to add a modular structure for scenes governing levels early on. However, physics simulation is something I definitely have less personal knowledge of, and therefore something I have to abdicate some control over. As the complexity grew, I wanted a way to iterate more quickly while automating correctness guarantees.

Test-driven development is not a new idea in software, and it’s one of the best ones—sort of a platonic ideal. It works incredibly for most logistical correctness guarantees. However, it seems hardly practical for most application development, particularly when using modern frontend and UI frameworks, which often depend heavily on the all-encompassing state and context of the app to execute anything.

AI can change this dramatically. The Bot is good at handling the particular idiosyncrasies that come with writing tests for specific frameworks—what state needs to be mocked around testing the actual logic that needs testing.

We also tend to feed bite-sized features to AI, which in a way is the pinnacle of what frameworks like cucumber attempt to achieve: articulating your test cases as plain English, so that they serve practically as a common specification.

So, for Galactic Golf, I devised an experiment to test this method. After generating an initial suite of tests for the features already implemented, my instructions for Claude would be: for every new use case, to write a test first. It would run the test, make sure it failed in an expected way, and then run the test again after implementing the feature—typical test-driven development.

My claude.md looks something like this:

## Testing Requirements

Every new feature must have tests. Follow TDD:

1. **Write tests first** in `tests/` before implementing the feature.
2. **Run tests before implementation** to confirm they fail:
   ```sh
   godot --headless --path . -s addons/gut/gut_cmdln.gd
   ```
3. **Implement the feature.**
4. **Run tests again** to confirm they pass.

Now I put it to the test with an extensive refactor. It’s good for refactors to have a clear product case: A couple of times, I had to make sure changes to ball physics also applied to the projected trajectory.

With the TDD framework, I asked Claude to refactor the code such that both ball and trajectory share physics, so we wouldn't need to make changes in two places.

Did the tests make this a flawless process? Not entirely. At first it didn’t understand that sharing the physics would mean more than just having a set of separate shared physics functions in the same file, it would mean that both code paths need to call on the same aggregate function.

When you tell Claude to go against its embedded behavior, it tends to revert to its old behavior in new context windows. So it’s worth noting I also told Claude to add a comment for itself so that it’ll remember to use the new function:

Did all of this help? Ultimately I’m not entirely sure. It’s always difficult to tell what incidents you’ve prevented. I’ve definitely still had to find many issues through manual testing, and then the other half of the time tests seem to be false positives—and just require a fix to the test itself.

I think it’s gotten better the more the codebase has evolved into tests driven by the actual use cases—beyond what was set up initially. Still, unit tests never tested whether something officially “works,” they just test that “it’s not broken in one particular way.” That’s maybe initially disappointing, but there’s real cumulative value in that.

It’s worth noting that this method consumes significantly more tokens. Luckily, I’ve configured Claude globally to use the caveman skill, which eliminates unnecessary LLM yapping (though it seems to have no effect on thinking). This allows me to even use Claude Opus (which I find is much better at refactors) by default on my $20 plan, only rarely running into my rate limit. I often find the default output way too wordy anyway; it becomes exhausting to parse during long sessions—ultimately not an efficient use of human brainpower either.

One thing’s for certain: even in the age of LLMs, there’s still great depth to be found in the field of Software Engineering. Many of the most interesting problems have always been—and remain—around how best to communicate complex problems and features precisely and efficiently.

From this perspective, it’s easy to see how agentic coding will only increase the need for Software Engineering as a field. It’s also easy to see how they’ll be an incredible point of advancement for the field itself, in giving us the greater means to leverage our principles.

By contrast, the lowest priced consumer subscription is typically $2.99 a month. Even at the lower end, that’s a vast difference from $0.015 a month. When such a large gap exists, it’s hard not to smell an opportunity.

Given this gap in price, you’re well motivated to do everything in your power to convert that Daily Active User into a paid subscriber. But doing that will…take quite some doing.

To begin with, most consumers do not want yet another subscription. On top of that, there’s payment processors, who charge a 7% fee on every one of these transactions. Paradoxically, these sources of friction make it hard to justify pushing your subscription price any lower.

And just what differentiates your paid service from your free one anyway? Typically, the subscription model resorts primarily to adding more and more ads until the user is over-encumbered by them—which I suppose is one way to marginally close the revenue/usage gap. It’s also playing a dangerous game with nuking your user engagement entirely.

I was asked recently if we all could simply do without ads. Wildly enough, in the opportunity to make more money, exists the opportunity for a better internet, better products, and a better internet.

To do that we’re going to take some good ideas from the past. Newspapers floundered under subscription models, but they thrived when you could buy one at the newsstand for 5 cents.

I’ve implemented a version of this on my own mod site, where downloads are available for a tiny fee.

There’s a key piece of infrastructure to make such an independent, granular model work. It’s the killer use case for Solana, an ultra-fast blockchain that has fees even more fractionally tiny than $0.015.

Whereas most modders rely on Patreon (subscriptions), I charge just 0.005 SOL per download, which (at the current time of writing) is 40 cents. The fee for the transaction is 0.00008 SOL, which is $0.0064. The fee wouldn’t be higher if I charged more.

Of course, there’s a variety of methods by which a business model like this could be accomplished. If one prefers a more internal approach, this can be implemented using a company’s own internal currency, and priced entirely through product-driven observable systems that give ultimate flexible control without the engineering lift.

On the opposite end of the spectrum for decentralized network effects, the SOL-based system could be integrated into existing ad bidding frameworks, allowing the user to be an active participant in their own ad auction. If the user wins, they aren’t shown an ad. This would close ads/subscription pricing gap in its totality, through the power of efficient markets.

Since everything is ultimately worth what its purchaser will pay for it, prioritizing market efficiency is the ultimate method for defining value. Let the invisible hand leverage your product-market fit.

It’s shown that Murderbot always looks slightly to the side of the head of anyone its talking to. What is not shown: typically in conversation Murderbot is not looking through its eyes at all. Given that it is security-specialized, it integrates whatever cameras are in its vicinity straight into in own perspective, and whenever possible, it will choose to look through the cameras to observe its own conversation. This sounds dissociative, but given how cameras might as well be its own body, it’s really not. (Cyberpunk 2077’s netrunner mechanics do a pretty decent job at depicting this, though I get the feeling it could be explored more deeply—and pushed further.)

But what causes Murderbot to be so uncomfortable looking at people head on in the first place? What might the difference in perspective be? Here’s where we tie it back to my fisheye lens, and how we might be able to replicate the perspective described in the book through environmental storytelling in gaming.

Fisheye lenses might offer a security bot—in its main camera from which it aims weapons—a tactical advantage. They widen the field of view past what is normal from a human perspective, and provide extra detail within the closer, narrower field. It might be great for first person shooter mechanics. It also is less specialized—and could provide some weird dynamics—interpersonally. You can see it back in Missy Elliot’s video, which is clearly designed to be a little freaky. If every conversation felt as up close as this—wouldn’t that make you uncomfortable?

Anyway, to truly test if this dynamic works, I need to create a shooter prototype running through my fisheye lens. I’d test 1) if you can shoot accurately, and 2) if I can leverage the lens to add some exaggerative flair to a close-up situation.

Thus, I created the game Barrels in a Fish. While you yourself are trapped in a barrel-shaped environment, barrels fall increasingly quickly from the sky. If you shoot the barrels, a myriad of random fish will explode out of them, gradually filling your view with close-ups of (dead) fish.

I managed to integrate my fisheye shader, cubemaps and all, with a godot game via cpp extension, which is pretty neat. The extension itself ended up significantly simpler than building it from scratch in vulkan was, although getting it to compile to wasm correctly—enabling it to be playable on web—involved a bit of trial and error.

I think the game yielded positive results for my hypotheses: I can still shoot accurately, and the lens made what was already an amusingly weird mechanic that much more impactful.

It also nicely closes a loop from the lens’ originally cited inspiration—we answer the question posed by Homestar: what happens if you point it at a real fish eye?

Last week we proved how it would be impossible to create a second pass that could sample a 2D first pass and achieve any semblance of quality. The view angle gets too steep:

Therefore, the only place we can tackle this is in the first pass. How could we improve the viewing angle? Well, we could bend the projection!

That sounds complicated though. (I realize I’m saying that after taking derivatives of trigonometric functions, but if nothing else we want to avoid the computer doing extra work!) What if…we just put in two sharp bends instead?

Add above and below to the equation and this, my friends, is the beginnings of a cubemap projection! Instead of mapping things continuously, anything in the first pass that would fall out of a (half) viewing angle θ of 45° is mapped onto the next square.

Our widest viewing angle, the trickiest place to sample, is now the corner of our cube. Our sample rate of change (that trigonometric derivative) sec²(θ), looking at the corner of our cube at 45° (a.k.a. π/4), does not approach infinity— sec²(π/4) is simply…2!

So at worst, we’ll need to sample at two times the sample rate at dead center. Perhaps a little challenging, but much more manageable than infinite.

And that’s what got a rendering like this:

To look like this!

And with that out of the way, we’ll be able to move on to talking about the fisheye lens math itself!

Particularly in the texture! Choosing one with lots of straight lines really highlighted the problem—downsampled straight line patterns have a tendency to create moiré patterns, consistent with those typically alleviated by applying Nyquist Sampling Theorem. The theorem boils down simply: to accurately capture a signal, sample at 2x the highest frequency.

The "frequency" here is spatial—how fast details change across the screen. The position on the screen per the view angle is determined by tan(θ):

As the angle increases, the rate at which the position on the 2D projection changes would be the derivative of tan(θ)—sec²(θ). Plug that into the calculator with, for example, 80°—you’ll find that the rate of change is ~33—in other words, one degree of change at 80° spreads across 33x the pixels. At 2x according to Nyquist, you’d need 66x the pixels!

Of course, it gets worse. Considering we’re doing a fisheye lens, we’re going to want to approach a field of view near 180°—and in the graph for sec²(θ), you can see that as you approach π/2 (90° for half the total FOV), we approach infinity:

And good luck getting enough samples for infinity, twice!

It’s clear that in order to sample for our fisheye lens properly we’re going to need a different projection for our first pass. What’ll we do instead? (You’ll find out next week!)

Each basic graphics pipeline has two points for transforming 3D positions into 2D screen coordinates: a vertex shader and a fragment shader. The vertex shader runs once for every vertex (corner point) in your 3D geometry. After the GPU figures out which pixels on screen are covered by a triangle, the fragment shader runs once per each of these triangles. Its job is to determine the color of that pixel.

My quadrilateral tax paper is made of 4 vertices and 2 triangle fragments:

When I try to apply distortion in the vertex shader, it gets the positioning right. But because it’s acting only on the vertices, when it comes to the interpolation between them, we still get straight lines.

A similar issue happens in the fragment shader. While the distortion looks sufficiently “bulbous,” well…it only applies per fragment:

(I wish I had made recordings of these states…let that be a lesson in why you don’t hide from your work until you get it right.)

If we were to mimic the real-life physics, what we’d need here is a finished view of the whole, and to then apply the distortion to the whole. So what we’ll do is set up two graphics pipelines. The first generates a fully rendered image, the second takes in that fully rendered image as a fragment and applies the fisheye distortion.

This process is really similar to the established practice of correcting VR lens distortion. VR headsets use wide-angle lenses placed close to the screen to create a sense of immersion. These lenses bend light in a way that causes pincushion distortion—straight lines bow inward, and the image stretches more toward the edges than the center. If you rendered a normal scene and just displayed it, it would look warped.

The trick is to intentionally apply the inverse distortion—barrel distortion—to the rendered image before it hits the lens. The lens then un-distorts it back. We’ll simply swap out barrel distortion for fisheye:

I did at least make a recording after I got the dual pipeline approach working!

You will however notice that the texture quality is terrible! But that’s a topic for next week!

Within this #1 Jam, Strong Bad asserts that you can make anything look cool with a Fish Eye Lens; but this is more than just memes, it’s established “Vibe Engineering” practice. Vibe Engineering (distinct from Vibe Coding) has one of its most important empirical demonstrations in Missy Elliot’s classic video for The Rain, where she utilized the very technique that Strong Bad emulates. Through this lens, she manages make a costume that is essentially an inflated garbage bag an iconic exploration of dynamic movement.

There’s one more thing in particular to note that Strong Bad and Coach Z mention: fish eyes used to be expensive, but now? Not so much. Indeed, many creative works have groundbreaking creative works have grown out of the technology to create them becoming cheaper and more accessible. In a categorical line of creative thinking, I’ve been exploring how to use the massive amount of modern graphics computing power for more creative game dynamics than just hyperrealism.

Thus, in the name of Vibe Engineering, I have sought out to create a fish eye lens using the Vulkan graphics library.

But before I even began to work on my new lens, I would need something to look at. Strong Bad and Coach Z provide a plethora of examples about how to make anything look cool, including the most innocuous items: tan pants, country dish towels…and tax papers. Since it’s Tax Season, I thought I’d use the latter example to add a little festivity.

As our starting point, here’s what a plain rendering of one such tax paper looks like:

I will diving deeper into the challenges of creating a fisheye lens in Vulkan over the next couple weeks. For an overview: it uses a similar technique to VR lens correction. We have two separate graphics pipelines: one to render the scene, and one to apply distortion over the full render finished previously. Using a cubemap prevents excessive quality loss over the parts of the model with enlarged detail. You can view the github repository here. But for now—behold!

What do you think? Is it cooler?

What is an iFrame?

An iframe is effectively a page within a page. It loads a specified url, which can come from any third party. Each iframe includes a separate layout engine, event system, and javascript heap, everything a different tab in your browser would. You can imagine this can get pretty performance heavy.

Despite their performance issues, iFrames can quite good for isolation, particularly if sandboxed. They can’t read content outside of themselves, which is why they’re used so predominantly for third party content like ads.

Hidden Data

While iFrames are originally intended to be viewable on the page, because of their isolating properties, they’re very typically used by third party tools to manage their own data. These iFrames are hidden from view typically by setting their width and height to 0 and/or using “display: none”.

But how necessary is this data? To understand this better, let’s examine a particularly predominant use of hidden iFrames: “usersync” frames.

Advertisers use usersync frames to sync anonymized identifier cookies with other partners. Company A knows you as "user123" while Company B knows you as "user789," and they need a way to realize these IDs refer to the same person.

• Your browser loads the iframe from the ad exchange’s domain

• The ad exchange reads its own cookie (e.g., “user123”) from your browser

• The iframe redirects to the partner’s domain

• The partner reads their own cookie (e.g., “user789”) and creates a mapping: exchange_id=user123 ↔ their_id=user789

• Both companies now know these IDs represent the same user

You can typically identify them by their sandbox parameters:

sandbox=”allow-scripts allow-same-origin”

The thing is, this process is typically finished fairly quickly. Unfortunately, these frames aren’t cleaned up automatically after they’ve served their purpose. You can do this yourself fairly easily however.

Have your page wait ~60 seconds, then use some classic jQuery to search for the signatures and remove them.

You can use the sandbox parameters above to identify usersync frames.

As for the rest of them, it’s tricky to say what every third party is doing in these iFrames (this is partly the point!) so, mainly this must be approached through experimentation.

In my experience, I’ve observed no ill effects in the data from simply cleaning up every hidden frame. On the flip side, this has had incredible effects on memory usage for longer running pages, reducing the load by 40%!

So, what are you waiting for? Smash your iFrames today!

But say you add just two more:

The number of possible code states begins to expand exponentially, 2^n to be precise, where n is the number of tests. That’s 2^n code states to manage, test, and monitor. And within each of these categories unique challenges are presented:

• Management — A/B tests encoded with feature flags are often ramped up manually, over long periods of time. Your organization has to remember to track them, and you’ll have to remember to clean them up when you’re done.

• Testing — Unit and Smoke tests by default usually test the “control” side of the test—the side with no experimental changes. You have to make sure to code in variations for each test, and that undermines a key value in automated testing: testing regressions on the periphery.

• Monitoring — With similar challenges to unit testing, monitoring also comes with a scale challenge. Monitors are typically built to detect drastic changes in traffic or behavior. If you’re testing on a small portion of traffic, drastic effects in your variations may not be visible to your monitors immediately.

So what can we do about this?

If you have continuous deployment, site traffic is likely already directed to a load balancer. When you make a new deploy, your load balancer switches from your old build to your new build.

We can use the load balancer to instead move traffic gradually from the old version of the site onto the new version.

This is called a “canary deploy,” and it can be done for every continuous deployment. This offers several advantages compared to feature flag A/B tests:

• They come with every deploy without extra effort for developers

• They are ramped up quickly and cleaned up just as fast

• Because divergent states aren’t allowed to compound, they are simpler to test and monitor

Of course, there are some times when you’ll want a more traditional A/B test. It’s likely that a few commits will go out with each deploy; if you require a high level of specificity, you’re better off using a feature flag. This often coincides with when you are testing a longer running feature, and are not just checking for big changes but for specific, incremental effects.

Nevertheless, there’s huge advantage to integrating canary deploy A/B tests into your CI/CD pipeline. As much as possible, we shouldn’t add special testing and monitoring infrastructure with every new feature—it should come baked in with every new feature automatically. In this way, we can iterate as quickly as possible without compromising quality or integrity.

Introducing Publish/Subscribe for Microservices

Everyone loves to reach for microservices, but in practice implementing them at your company can be an uphill battle. More than likely, it’s just that you’re missing one crucial piece.

Last week I talked about event-driven systems. In contrast to typical REST systems, that are stateless and require “pulling” data at a client’s request, event-driven systems “push” data to services that consume them.

This model is incredibly useful in high throughput real-time systems, largely due to the dependency inversion I discuss in the article linked above. As Tim Burglund demonstrates in his Apache Kafka video, having a push model and stateful log naturally begets the microservices model. Suddenly, microservices can be a natural consequence of engineers leveraging a particularly useful piece in their architecture stack, not something that needs to be constantly enforced.

But crucially this also facilitates a particular degree of statefulness amongst distributed systems. In addition to the raw event log Kafka automatically records, this also enables us to run real-time aggregate jobs at scale, which are highly useful for ads metrics.

The Real Cost of Latency

At high scale, the real cost is not individual message latency, but how efficiently a system can process large volumes of events. Architectures that support batching and parallel consumption can sustain far higher throughput with less infrastructure.

Log-based systems like Kafka are designed to process events in large batches, which reduces per-event overhead and allows real-time pipelines to scale efficiently. Systems that emphasize per-message delivery and acknowledgements can require more concurrent consumers to keep up as volume grows, increasing operational cost.

Conclusion

Running a successful ads business necessitates highly accurate real-time metrics at scale. The technology is there, and it’s open source. Adopting these technologies for the revenue side of the business is also a perfect moment for revenue teams to lead great architecture decisions company-wide.

If you’ve ever poked around with game modding, you might notice that many games provide a fantastic amount of leverage to mod with without ever having to touch the code. How do they do this? Through the magic of XML tuning files.

What can Web learn from Games?

XML tuning files have a close analog in server-driven UI (SDUI). SDUI typically uses JSON to define how a component looks. For example:

{
  "type": "Card",
  "title": "Upgrade",
  "cta": { "label": "Buy" }
}

This, however, can go further. In addition to styling, you can also encode your data system to pick up queues for interactivity.

I’ve written quite a few game mods that encode a complex interaction chain: a particular effect is triggered, which on an auto-resolve curve; i.e., the effect is taken off after a given amount of time. On resolution, it presents a different effect, which in turn has its own auto-resolution. I didn’t have to touch the game scripts at all for these; these gameplay effects can be encoded entirely through XML.

To illustrate an example for the Web, imagine you knew you wanted to reward users “coins.” You’re not sure exactly how you want to grant or use those coins yet (economies are complex), and you want to experiment iteratively. If you have components specified through data, you can also define a field that specifies a number of coins to grant—on any component you want.

{
  "type": "Button",
  "title": "Upgrade",
  "cta": { "label": "Buy" },
  "coins": 100
}

You could go even further and specify a level of randomness:

{
  "type": "Button",
  "title": "Upgrade",
  "cta": { "label": "Buy" },
  "coins": 100,
  "randomness": 10 // granted +/- 10 the amount of coins listed above
}

Or even specify a level of compounding:

{
  "type": "Button",
  "title": "Upgrade",
  "cta": { "label": "Buy" },
  "coins": 100,
  "randomness": 10 // granted +/- 10 the amount of coins listed above
  "gain": x * 1.01 // gain 1% of the initial value each subsequent time
}

Decoupled, Event-Driven, Config-Driven Systems

When everything is specified in data files, your system becomes very easily auditable. Just as these data files are parsed into your code, they can be parsed into a configuration system where you can get an overview of each effect. For example, if you, as a product manager, wanted to get an overview of each interaction on your site that supports granting coins, that’s something that’s easily readable like a spreadsheet.

But how exactly do you parse and support these data files within your code as a developer? Through event-driven architecture. I once built a poker game with Solana blockchain rails that used websockets as the primary communication method between client and server. Contrasted to REST APIs, websockets are a push-pull model that require you to specify an event type for each event sent—such is event driven architecture. These types are easily leveraged in json files to enforce a data specification.

And using event-driven architecture has one massive advantage in particular—decoupling. When an event “producer” (e.g. a button is clicked) and an event “consumer” (e.g. a wallet counting how many coins you have) are decoupled, they do not know about each other. You can modify, redeploy, or even delete a consumer without touching the producer, and vice versa. This sharply reduces coordination cost and regression risk.

Consider an e-commerce product where the core checkout service emits an event called “OrderPlaced.”

The checkout team owns only one responsibility: validate payment, create the order, and publish that event. They do not know or care what happens next.

Design and product want to experiment with several things at once:
• a new post-purchase email flow
• a “people also bought” recommendation widget
• a loyalty points system
• a fraud-scoring model

In a tightly coupled system, each of those would require the checkout engineers to add logic, call new APIs, deploy new code, and take on risk. Product and design would have to file tickets, wait for sprint planning, and negotiate priorities just to run an experiment.

Decoupling vastly improves system extensibility. New behavior is added by subscribing to existing events rather than modifying existing code paths. So, as a designer or a product manager, you can attach a new analytics pipeline, billing rule, or notification system without having to have engineers change the service that emits an event “PlaceOrder.”

Conclusion

Data config-driven systems can fulfill a product team’s wildest dreams—and event-driven architecture is the engineering backbone that makes it happen. It’s embraced in many high-performance applications—embracing it can allow Web companies to scale their teams’ velocity to unprecedented levels, and provide extraordinary leverage for the business.

What happens here? Well, thankfully it’s nothing insurmountable. In fact, leveraging server-side rendering unlocks some of the most powerful architectures for improving both your page performance and your ad auction performance.

Loading Your Scripts

Third party ads libraries such as Prebid.js, Google Publisher Tag, and TAM are loaded with script tags—this is in part because they attach globally to your browser’s window object.

It’s useful then to know with precision when exactly the window object is created in a Next.js lifecycle. Often advice in this area assumes you should wait post-hydration to allow scripts to capture the window object, but the window object is available after the first server-side render.

Thus, when you first start using Next.js with ads, you might receive the advice to use “afterInteractive” on all your script tags. This isn’t strictly necessary. In fact, if you don’t load your scripts as “beforeInteractive,” you could be missing out on revenue, since loading the scripts sooner means your ads can load sooner.

Command Queues

With GPT, instead of waiting for hydration, you can use the “defer” keyword on your script tag to ensure that execution waits until just after HTML parsing.

<script defer src="gpt.js" />

You can then predefine command queues:

  window.googletag = window.googletag || {};
  googletag.cmd = googletag.cmd || [];

This is the exact formula googletag uses internally to attach to the window object. Once the script finishes loading, it will use what’s there, and attach to the window object internally, so there won’t be any synchronization issues. You’re then free to use the `async` keyword:

<script async src="gpt.js" />

This means you can attach commands to the command queue even if your scripts aren’t loaded yet. The command queue allows you to continue setup functions before the script is fully loaded:

googletag.cmd.push(function() {
  googletag.defineSlot(...);
});

This is dependency inversion, and it comes up repeatedly to resolve tough asynchronous execution knots. Interestingly, this comes up a lot in GPU programming as well—if your pipelines have a queue to pop commands off from, it means the pipeline can consume it as soon as it decides it’s ready, instead of waiting for something external that presumes it isn’t.

Single Request Architecture

This dependency inversion enables us to leverage one particularly powerful googletag feature—Single Request Architecture:

googletag.cmd.push(() => {
  googletag.pubads().enableSingleRequest();
  googletag.enableServices();
});

This tells googletag to batch all eligible ad slots into a single network request. This is designed specifically for server-rendered pages. The critical constraint here is that all slots you want in the batch must be defined—and otherwise ready (i.e. header bidding is completed)—before the first “googletag.display” call.

This is a killer reason to get your slot definitions going pre-hydration. Fewer network requests has performance benefits—reducing RTT and main thread contention—but the real benefit is in what Google Ad Manager does with a bundled request: it enables portfolio-level optimization. Advertisers want reach and context, and giving them that context increases their willingness to bid. This also allows Google Ad Manager to evaluate your set of ads as a whole, and unlock bundle-based pricing.

Duplicate Definitions

One gotcha here is that you must make sure not to define the slot twice—this can happen if, for example, you use strict mode. I recommend creating an object from which to manage all your ads scripts that is built from a “once” function.

Client-Side Navigation

Once you have your initial page load correct, there’s just one more thing you need to worry about: client-side navigation.

While it’s useful overall for page performance to not reload everything every time a link is clicked, without a page reload your ad scripts won’t know to load new ads.

This simply means you have to refresh your ads manually when your navigation route changes, e.g.:

“use client”;
import { useEffect } from “react”;
import { usePathname } from “next/navigation”;

export default function GamRefresh() {
  const path = usePathname();

  useEffect(() => {
    if (window.googletag?.pubads) {
      googletag.pubads().refresh();
    }
  }, [path]);

  return null;
}

Conclusion

When you first attempt to convert to a static site generator, it might look like a daunting regression. With just a few tweaks, however, you can see both your site’s performance and revenue leap ahead. It’s worth the investment!

If you’d like to explore more about how to optimize your ads, I recommend examining how collapsible ad slots can hurt CLS.

Cumulative Layout Shift (CLS) is one of Google’s Core Web Vitals. The Core Web Vitals are a base measure user experience on your page, and affect search rankings. CLS in particular measures how much the page “shifts around” as it loads.

An ad slot that is collapsed while it loads, and expands once it does, is then naturally going to have negative effects on your CLS metric.

So what can you do instead?

Avoid Disruptive Positioning

One method to fix this is to avoid ads embedded in your content—this is where classic sidebar ads shine. While perhaps a little old fashioned, sidebar ads are tried and true. They typically have high viewability, and thus excellent profitability. They are also minimally disruptive to your user’s experience; they don’t get in the way of what your user came here to see.

Fetch Ads Before Slots Render At All

More fashionably, if you have an infinite scroll feed on your site, the UI for subsequent content is typically loaded in chunks. Ads can be stealthily requested just before a new feed section is likely to be requested. This allows a decision to be made as to whether or not to render the slot based on whether or not the pre-fetched ad request fills.

Backfill Ads with Your Own Subscription Upsell

If you have ads that are part of your initial page load, and are also positioned to disrupt content—for example, a large “billboard”-style header ad—the cleanest way to handle cases where an ad fails to catch a bid is to use the unfilled inventory yourself. You likely also sell a subscription—this is the perfect opportunity to promote it.

Ads are often described as a necessary evil. But when done well, they can provide maximum value to both your business and your user, while minimally disrupting your intended experience.

Subscribe now