If you’ve spent any time in GOALS, you know the feeling. You pull a new player, and your eyes immediately dart to the numbers. Maybe you’ve landed a Center Back with 85 Physicality but surprisingly decent Passing. Or perhaps a Striker with electric Pace but a Finishing stat that needs some work.
To the naked eye, this looks like simple RNG. It feels like we rolled a 100-sided die 31 times, slapped a name on the result, and sent it to your inventory.
But if we actually did that, the game would be broken in minutes. You’d have goalkeepers with 99 Reflexes and 12 Handling. You’d have 95-rated Strikers who are actually better at defending than your CBs.
The reality is much more complex. Generating millions of unique, balanced, and competitive players in a millisecond is not just a coding challenge; it is a massive geometry problem.
Today, we’re going to peel back the curtain on the math that powers the GOALS’s squads. We’ll look at how we moved from simple spreadsheets to 31-dimensional geometry, and why finding your next Legend requires us to surf a hyperplane.
The "It’s Not Just Random" Problem
Let’s start with the constraints. A GOALS player isn’t just a bag of numbers; they are a cohesive athletic profile defined by 31 different attributes. These range from the obvious—like Sprint Speed and Shot Power—to the granular, like Defensive IQ and Curve.
If we just randomized these independently, we would lose the "soul" of the positions. We have strict rules in place to ensure the game feels like football:
1. The Mainstats Relationship: Attributes are grouped under "mainstats," like Shooting or Dribbling. A mainstat is a weighted compound of all its sub-stats. If a player has high Finishing and Penalties, their Shooting main stat is calculated from those weighted values. We then apply extra constraints to ensure the individual stats stay within a realistic range of that calculated total, so you never end up with a 90-rated shooter who somehow has a 10 in Long Shots.
2. Dependency Constraints: Some stats rely on each other. We enforce "spread" constraints, meaning specific pairs of stats need to be within a certain distance of one another to maintain realism.
3. The Positional Hierarchy: This is the big one. When the server generates a Striker with an 80 Overall Rating, that rating is a weighted sum of specific stats relevant to strikers. But here is the kicker: that same player, if rated as any other role than Striker, must have a lower rating than 80.
Visualizing the Impossible
So, we have 31 variables and a massive list of rules (linear inequalities). How do we solve this?
We stop thinking about them as stats and start thinking about them as coordinates.
Imagine a player as a single dot on a map. If a player had only three stats, that dot would live inside a 3D cube. But because we have 31 stats, every GOALS player exists as a point in a 31-dimensional space.
Every rule we apply—like "Maximum Pace is 99" or "Standing Tackle must be close to Sliding Tackle"—acts like a cliff face or a canyon wall slicing through that space. When you apply all these walls, you carve out a specific geometric landscape called a Convex Polytope.
Inside this landscape lies every single valid player that can possibly exist in GOALS. Outside the cliffs are the broken players (the goalies with 99 shooting).
Hiking the Hyperplane
Now, let’s say the server needs to generate an 82-rated Midfielder. We can't just pick any spot on the map. We need a player whose weighted stats add up exactly to 82 .
This creates a Hyperplane .
Think of the Convex Polytope as a massive, rugged mountain range. Our job is to find a spot on the mountain that is exactly at that altitude, but still safely within the boundaries of the explorable terrain (the constraints).
We need to drop a hiker onto this specific trail and have them wander around to find a unique spot. Here is how the hike works in plain English:
1. Spin the Compass: Standing at a valid spot on the trail (the Hyperplane), our virtual hiker spins a compass to pick a completely random direction to walk.
2. Spot the Cliffs: The hiker looks in that direction and calculates exactly how far they can walk before they fall off the map (hitting a constraint, like a stat going above 99).
3. Travel: They pick a random distance along that path and hike there. That new stopping point is our new player.
4. Long hike: walk long enough so that you don’t end up too close to the other spot. If they start at a clearing that looks like a Wing Back and only take one short walk, the new spot will probably still look like a Wing Back. In math terms, the samples are highly correlated. We don't want to give you a player that is essentially a clone of the last one generated.
This means that every time you open a pack, you are getting a fresh, mathematically distinct profile that satisfies every single rule in our 31-dimensional rulebook.
So what?
Why go through all this trouble? Why not just use a lookup table or simple randomization?
Because we want each Player in GOALS to feel unique -creating vast and varied options for different playstyle. We want a world where two players can have the exact same Overall Rating and Position, yet feel completely different on the pitch. From the physical tank to the nimble technician.
It’s complex geometry, running in milliseconds, just so you can find that one hidden gem of a striker.
Want the full math explained? Read this thesis that was written solely for solving this problem for GOALS.
See you on the pitch.
Jonas Rundberg, GOALS