Building Foundations 5: Utility
Some of you may have already seen the writing on the wall in regards to this post. Well, it’s time to make it official: what I have been dancing around with all the taxonomies was the idea of utility functions. This post will explain what those are for those of you who don’t already know, why they are useful, and why they still remain useful as a concept even when no mathematical formulation of such a function can be written down.
Mostly, I just want to introduce an actual noun for the concept of measurable fun, because writing around it is becoming tiresome.
As usual, if you are confused about any terms, make sure to check out the glossary, and if you are looking for other posts, check out the blog map.
Imagine that you are an economist, and you are trying to model people’s preferences. To give a real-world example, let’s say you were hired to help with planning out shelves in a supermarket, and you are trying to figure out how much space to allocate for fruits, how much for bread and how much for meat, based on people’s preferences for all those three things. There is a lot of money hanging on this question, so you are really motivated to get it right.
Now, you are a smart economist, so you went out and asked a bunch of potential customers how much space they’d prefer allocated for each of those things. Say you let them put together an ordered list of preferences, such that they prefer first choice to the second one, second to the third, and so on. For example, someone might prefer a 50%/20%/30% (fruits/bread/meat) breakdown of the shelves to 40/30/30, and 40/30/30 to 30/30/40. You now have a lot of data to analyse, but there is one problem: such ordered lists are very inconvenient to analyse between hundreds of different people. Furthermore, they don’t really tell you how much people prefer one option to another: maybe someone feels really strongly about some orders, but not others.
Fortunately, there is a way to solve both problems with one method, and that method is utility functions. Instead of turning this information into a list, we give each option a “utility value” - a number that tells us how much you like it. If one option has a higher utility value (or utility for short) than another, then you like it more. Difference in utilities also tells us how much more you prefer one option to another - small differences mean you have a small preference, and larger ones mean a larger one.
For this method to work, two assumptions have to be true. First of all, for any two alternatives A and B, you should be able to tell if you prefer A to B, B to A, or if you have no preference one way or another. Secondly, preferences have to be transitive: that is to say, if you prefer A to B and B to C, then you also prefer A to C. Put another way: you shouldn’t have cyclical preferences, where you prefer option A to B, B to C, and C to A. Sometimes humans do seem to have cyclical preferences, so the method isn’t perfect, but in general it works pretty well.
What does this allow us to do? Well, for one, you can now predict how people will rate options you didn’t ask them about. Imagine that you have asked them to rate 40 different shop configurations on a scale from 1 to 1000: you now have 40 points on a utility graph, and can interpolate values in between those points. This can let you analyse how they’d probably feel about thousands of different shop configurations, without having to go and ask them thousands of questions.
Secondly, this lets you make sensible trade-offs between values of different people. Not everyone has the same preferences, and some people feel much stronger about some choices compared to others. By using the utility approach, we can put the degrees of preference all on the same scale. Then making preference trade-offs becomes a mathematical problem, easily solved by a computer.
This is all excellent, but what does this have to do with PNP RPGs?
Well, very simple: we can model the types of fun described in previous taxonomies as separate parts of player (or game master) utility functions. If we represent the amount of any particular type of fun (for example, in time) the player gets as a number, then utility function’s form must be a function of those amounts, and of the degree of preference for them.
However, there is no way we are going to be asking players hundreds of questions to narrow down the actual mathematical formula for their utility function. What good does this bring us then?
Well, several things.
First of all, this, in my opinion, completely formalizes the question of what is the fundamental problem of Pen and Paper Role-Playing Games: it is maximization of the (weighted) sum of utility functions of the players and the GM. GM, as mentioned before, gets a slightly higher weight. With the problem defined to this degree, if we had a computer that could write stories (looking at you, GPT-type transformers), some way to get enough data to write the utility functions, and some time to put it all together, we could in principle cut the GM out of the loop entirely. I leave this as an exercise for the reader.
Secondly, this makes the idea of trading off one type of fun for another explicit, and likewise for trading off the fun of one player for the fun of another. This will be very relevant later on.
You may say that this seems like a very roundabout way to get to this point: everyone knows you can’t have everything at once, and so of course you will have to make trade-offs between different types of fun. Why descend into mathematics for this?
My answer to this is that when I hear other people talk about how to deal with different players having conflicting desires, the idea of making trade-offs comes off as just another trick in a long series of tricks you can use to reach a good outcome. By descending into mathematics, we can show that this isn’t just another trick: this is a mathematically inevitable outcome of trying to find a compromise between people with differing preferences.
Next advantage of putting players’ fun in terms of utility is that we can apply some findings from other fields that use utility modeling to the PNP RPG scene. For example, I find it extremely likely that players’ utility is concave in amount of fun, in much the same way that utility is normally concave in dollars. That is to say that amount of utility you achieve from some particular fun type is larger when you are currently unfulfilled in that fun type, as opposed to when you already get lots of it.
Finally, now I can say “utility (function) of person X” instead of “those types of fun player or GM X likes and types of unfun they dislike”, or “person X gains more utility from choice Y than choice Z” instead of “choice Y satisfies some type of fun (or several) that person X enjoys more than choice Z does”. This should make writing significantly simpler.
Meanwhile, if you enjoy what I write, you can subscribe to receive updates by email: