For the last month and a half, I’ve been working nonstop on a project attempting to illustrate what I believe to be a new way to look at golf design. And after more consecutive late nights of coding than I’d like to admit to my partner, I’ve finally cleared the first big hurdle. Here, I’m going to walk through the tool I’ve been furiously building from scratch to bring my way of looking at golf architecture – an expansion on Mark Broadie’s foundational strokes gained approach – to life.

It’s going to get a bit technical, so please bear with me.

For years, I have – simultaneously – been extremely frustrated by the “strokes gained” approach to golf laid out by Mark Broadie, while also openly telling everyone that it is both obviously correct and is probably the most important step forward in explaining the game to have been achieved in my lifetime. I don’t want to disparage Broadie or his thesis here: it is sound and rightly influential. By using the benchmark of average strokes to hole, players are able to solve for shot-for-shot performance, find the weakest part of their game, improve, etc. It’s everything golf should be about. Broadie bases everything in analytics, on real world data.

But I’ve always felt a constant nagging that something was missing. My frustration was clear: where is the room for strategic architecture in a theory where only distance matters? The frustration was so persistent that I even bought and read through Broadie’s book, Every Shot Counts, to make sure I wasn’t missing any aspects of the thesis that might take care of the problem of strategy.

The strokes gained benchmarking system requires “like-for-like” comparison, and, to be perfectly honest, using distance is an entirely reasonable way to do a comparison. I just kept thinking about how some positions on the golf course are better than others, even when they are both the same distance from the hole. An obvious example would be two shots of the same distance, but one is taken from the fairway and the other from a bunker. The strokes gained approach would treat these shots as different in kind: hitting off the fairway vs sand vs rough are not like-for-like shots. They must be benchmarked against other shots from the same distance of the same kind.

For me though, when looking at golf hole design, this still doesn’t go far enough. If we care about design, then the same shot from two different angles simply can’t be the same shot. If a green tilts left-to-right, it should be easier to approach from the right side than the left side. Why? A shot from the right side hits the green where it’s tilted toward the player, which helps stop the ball. A shot from the left is just more likely to run off the green. When we start averaging these shots together, we lose the strategic positional elements through dilution. So, how can a theory as obviously correct and effective as Broadie’s still be unsatisfying? I sat with this conundrum for years.

I finally found my solution by leaning into the theory instead of pushing back against it. Okay, fair enough. Strokes-to-hole is obviously the most important metric we should be looking at, so let’s look at a world where the only thing that matters is distance.

Let’s say we have a golf hole with no features: no bunkers, no contours, and everything is a perfectly flat fairway. Playing this hole is effectively an applied driving range exercise. This is a world in which only distance matters. This is a place where I fully endorse the strokes gained approach.

Here the solution becomes clear: if we play golf in a world where only distance matters, then let that be our benchmark. Forget the real world (I’m a philosopher by training, after all). If we set our benchmark on an idealized plane, then we can use that benchmark to explain the real world. Forget the golfer, and forget measuring the golfer’s shots. Instead, what if we use the golfer’s shots to measure the hole itself?

The idea is this:

1. First, set our benchmark as a player’s strokes-to-hole at every point on an idealized plane.

2. Next, calculate the same player’s strokes-to-hole on the actual version of the hole, but we have to do it at every single position.

3. Now, if we subtract the idealized strokes-to-hole from the actual strokes-to-hole, then we can see a map of where that hole is difficult, and where it is easy.

That’s it. We can use strokes gained not just as a way to look at player performance, but as a way to look at golf course architecture. I had a new thesis, and at that point, all I had to do to act on it was figure out a way to calculate a player’s strokes-to-hole at every point on a golf hole. The good news is that I have a computer and I know how to use it.

So, I literally spent the last month and a half building a golf simulator, with a built-in algorithm whose sole purpose is to calculate the strokes-to-hole at every point on the golf hole you give it. And now I get to show you all the pretty pictures this program makes.

After the simulator runs, you end up with some images that look like the ones above. So, let me explain what we are looking at here. From left to right:

• First, the regular hole map. This is just how the vast majority of folks see a golf hole.

• Next, we have a perfect Broadie map: strokes-to-hole captured at every point. If you can beat the strokes-to-hole on this map, you’ve gained strokes.

• Next, we have the functional Broadie map. Since there is no practical way to measure strokes-to-hole in the real world, we just average all the fairway numbers together, and what we are left with is a strokes-to-hole map where distance is the only variable.

• Finally, we have the Schoolfield map. We’ve subtracted the actual strokes-to-hole from the idealized strokes-to-hole, and we are left with the strokes-to-hole penalty. Here, the redder the area of play, the more difficult it will be to finish the hole compared to an idealized scenario.

What is most interesting about this last heatmap is that it shows the net effect of all the hazards and contours on the player’s position. So what do we see here?

• First, we see the water hazard is dark red. It is dark red because being in the hazard means you need to drop, and that drop is costing you a full stroke – importantly – when compared to an idealized scenario, because if that water were fairway, you wouldn’t need a drop.

• Next we see that both of the greenside bunkers are bright red, because the model suggests that playing out of those bunkers will likely add about a half a stroke (compared to if they were just flat fairway).

• Next, we notice the yellowish-orange centerline bunker. The model here suggests that this bunker will cost us around 0.2 strokes compared to if it were fairway. This is much less, because the green is reachable from the sand, and the penalty is mostly wrapped up in a wider dispersion pattern.

• Finally, we see a ring of orange. This is the distance where the model has the player hitting a three wood or four iron in. The player can’t quite reach the green comfortably so the dispersion pattern is large, and the greenside bunkers are heavily in play. If they weren’t there, in the ideal world, a player would just hit it as close as possible without concern. But because so much sand is in play, the player should have 0.15 added strokes when finishing the hole.

It’s important to note here that this map is only relevant to a player of this skill (this map is simulating a “5 HCP” but that is intentionally vague and effectively unrealistic for real world conditions). This isn’t “the way the hole looks to everyone” because not everyone is going to consistently hit the same strokes-to-hole from the same location, or even from an ideal location. For better players, hitting out of a fairway bunker is more recoverable than for beginners, and any greenside bunker will in play for a higher handicapper, but scratch players are rarely affected by them with a wedge in their hands.

The hole above has very obvious hazards and the resulting image is not particularly surprising. This process is most interesting when we look at strategic design features that are hard to parse in the real world. So, let’s look at a case study from history.

Often considered the first instance of strategic golf, the fourth at Woking is an excellent candidate to look at how golf course architecture can be visualized via this method. Fried Egg Golf has a fantastic article about the history and strategic interest of the hole, and in that article you can see Tom Simpson’s sketch that I have used here.

Generally, the hole is defined by two hazardous areas: out-of-bounds along the right side and the bunker complex in the middle of the fairway. Though, by the green, there are also two small greenside bunkers short-left, and a larger bunker that shots should roll towards on the right.

Here, I’ve added some length to the historic hole to help it fit longer modern distances. I’ve also added some topography, which is based on the note that Simpson has under his sketch:

I’ve also overlaid the “A” and “B” markers and some parts of his illustration:

While it may seem obvious on the strategic player or skilled golf architect, by using this mapping process we can just see exactly why the shot to “A” is so advantageous, and even why playing to “B” is a good idea . However, assuming the model accurately approximates how a person plays, we can also see that there is only a tiny advantage to playing to “B” rather than playing a safe shot left. The illustration just allows one to see the advantages and disadvantages, clear as day.

Importantly, however, this process DOES NOT tell us whether or not we should attempt to reach “A,” or whether we should lay up “B,” or even play left. Determining where to aim requires an entirely different algorithm, which I did have to write to build this program, but that is beyond the scope of this article. I just wanted to reiterate here that the green zones on these maps are “places that are nice to be,” but getting to those areas is a problem for the player to solve, and I will discuss some very clear examples of how and when to do that in subsequent articles on this system.

First and foremost, I want to say, explicitly, that this model does not reflect actual reality. This model was built as a purely theoretical exercise to apply the ideas I had, and to try to build something that demonstrated them. Hopefully though, it can be improved to the point where it is a practical tool for designers to communicate architectural ideas to clients who are trying to build or improve golf experiences.

I have to take a lot of shortcuts in building these maps because the number of calculations I have to run for every single pixel is very large. Now, I’ve built some pretty sophisticated ways to get around these problems, but again shortcuts are shortcuts, and taking them necessarily moves us away from reality. Here let’s look at just a few of the limitations in creating these maps that I ought to disclose, and at this point I will need to be unapologetically technical.

The first issue is the resolution of the course itself. The problem here is that we need to calculate an average of strokes-to-hole from every point on the golf hole. In saying “every point,” we obviously have to turn a continuous problem into a discrete problem, and the choice of what level of resolution to use is non-trivial. Right now, when I set that resolution to only make a calculation for each two-yard by two-yard square, I can get the map done in a couple minutes. When I set the resolution at one foot by one foot, the process usually takes over an hour. TL;DR: I can make maps for shots from general areas on a hole pretty quickly, but as I get closer to mapping “every point” on a hole, it gets exponentially more time consuming.

Next is the resolution of shot distribution. So, we have calculated average strokes-to-hole, and I’ve chosen to do that by using a bivariate probability density function, which seems like the simplest, most straightforward method (though I would like to improve that if I can get access to analytics data). So, calculating the average means I need to calculate some number of shots from every position. Without even getting into the complexity of deciding where to hit those shots, when we have decided to hit a shot, we have to do it enough times to account for the various features of the golf course we are trying to illustrate. Right now, when I’m trying to get the job done quickly, I do the average of 50 different shots at a regular distribution. When I’m trying to do a high-resolution version, I’m using an average of 200 different shots. TL;DR: as with the previous resolution issue, accounting for more types of shots taken increases the time this takes by a huge factor.

Yet another confounding issue is resolution of rollout. The way a shot interacts with the ground is hugely important to the underlying theory. A central focus of this exercise is just illustrating that it’s harder to stop a shot on a green that’s tilted away from you than it is on one that’s tilted towards you.

One way that we think about calculating the rollout from a shot is as a series of vector additions. Imagine we were recording a shot’s rollout on a film camera. Theoretically, we could look at each frame, and in the frame calculate the velocity of the ball and add in the friction of the ground, and the effect of gravity, and with all that info we should be able to predict where the ball will be in the next frame. The “resolution” here is how many frames per second we are looking at.

If we did 60 frames per second, we’d be doing 5X the work of doing 12 frames per second. For each frame, we also need to run a number of calculations – let’s say, do three calculations per frame. Three calculations per frame, multiplied by 5X the amount of work for 60 frames vs. 12 frames, ends up being 15X the amount of work we started with in that 12 frames per second scenario. And we’re doing that for every shot we simulate, from every pixel we are simulating it from. The problem quickly becomes NP hard. Thank goodness for linear algebra! TL;DR: adding more variables, while important, exponentially increases the work needed.

These maps show how one player would interact with the golf course. Right now I have it set to a theoretical “5 HCP” player, but in reality, every single 5 HCP plays differently. Some people are long hitters who need a wedge in their hand to convert. Others are deadly accurate from inside 200 yards, but might be a bit short off the tee. Some folks can get out of trouble with a full swing where others will just lay up. Right now the program can’t account for Wild Willies or Steady Eddies: it just calculates Linear Larry, a theoretical golfer who just gets uniformly longer and more accurate as we dial down his handicap. The fact that everyone plays differently means that even if we can see the effects of the architecture from 10,000 feet, how much that might apply to different players is highly variable depending on the features.

Note here that the higher handicapper completely loses the advantages for being on the right side. Using the software we can see that this is mostly due to the simulated player’s exaggerated long-left, short-right miss, which is quite wide. This seems to fit neatly across the green, avoiding the bunkers and out of bounds. Here, obviously, better player modeling would create more accurate results.

This program is still a prototype. I’ve been writing it as fast as I can, but every single corner case brings more and more computational complexity. Figuring out how to model putting – at this point – feels a bit insurmountable, but I’m sure I’ll figure something out. Right now, the model just uses publicly available strokes gained data to automatically return the expected value at a given distance. In this way, I fall back on exactly the type of practical analytics that Broadie does, simply because it actually works pretty well. Still, if I want to create a model that eventually reflects reality, it needs to be able to do the same strokes-to-hole calculations with a putter as it does with a wedge. Adding trees will actually be fairly easy by comparison, but, again, these things take time. The model is really just at the point where I’m not actively embarrassed to share it publicly.

I’ve barely scratched the surface on what this model can illustrate, but this article is already quite long. I just wanted to communicate the general concept here before moving onto more specific areas of strategic architecture and design. I am able to use this and other maps to highlight different types of strategic elements in the game. I’ll include some of those images here as teasers:

I’m going to be completely honest here: I really think that even at this early stage, this model could be super useful for architects in the industry, simply as a way to communicate their ideas with clients, especially when the client is a club with a large membership where it can be difficult to communicate with everyone. So for anyone working on a project with a simple topo map, I’d love to hear from you. I’ll soon be trying to integrate publicly available lidar topos where there are interesting courses to overlay in the model.

While I still have more to explain and discuss about the model here, it’s clear that, as a solo developer, I’ll soon be bumping up against the limits of realism I’ll be able to replicate without access to (1) datasets of player data, (2) topographical maps of courses with reasonable resolution, and (3) academic knowledge about the physical behavior of golf balls on different surfaces. I’m interested in exploring ways to keep pursuing this research, potentially within an academic setting or through a partnership with architects who might find these types of illustrations valuable. If you’re interested in using this engine for a project, or if you’re involved in research and see a home for this kind of methodology, I’d love to compare notes. Feel free to reach out through Substack, leave me a comment, or message me here.