19
\$\begingroup\$

This was a question asked during an interview, and I was absolutely stumped.

Let's say that there's a levelling system in the game. If you defeat an enemy, you get "n" XP. By the time you reach "nTotal" of Lvl 1, you progress to Lvl 2.

But how do you decide what numbers "n" and "nTotal" are going to be in the first place? What sort of decisions ride behind setting it to a very particular number before they're fed into an algorithm that automates its exponential/linear increase every level afterwards?

I get that this is done with a trial-and-error approach down the line, but I don't know what the initial approach is when setting it the first time around.

\$\endgroup\$

2 Answers 2

38
\$\begingroup\$

When interviewers ask you a question like this, they're usually not looking for you to know "the correct answer" off the top of your head, like "n = 10, nTotal = 1000, next!"

Instead, they want to get a sense of your process as a designer:

  • What factors do you consider?
  • What kinds of questions do you ask?
  • How do you weigh your attention / priorities between different aspects?
  • What tools do you bring to bear?
  • How do you communicate about it (e.g. in words or diagramming on whiteboards)?

If I were asking this question in an interview, some of the things I'd be watching and listening for would include:

  • Does the candidate recognize this is really a question about the player's time and the pacing of action / progression?
    • \$ \frac {\text{nTotal}} {n} = \text{# battles before first level-up}\$
    • What are their heuristics for how many battles would be good to aim for, or how long this should take in terms of play time?
    • Why are they choosing those heuristics? Are they stating them, or just assuming them as universal?
  • Do they ask about the context of this game and its target experience goals? (We might use much more rapid pacing for early levels in a mobile / free-to-play game, or slower pacing in a story-focused game where the focus is not on combat grind at the start)
    • If not, what context / target experience are they assuming? Is it aligned with our project?
    • I find junior design candidates are often afraid to ask questions, thinking it makes them look unknowledgeable. But myself, I like it when designers ask questions, because it tells me they realize there are things they don't know, and that their team is a resource to learn from.
  • Are they thinking about the impacts of particular kinds of numbers?
    • Low values of n can limit the granularity with which we can make enemies "a little stronger / more valuable" or a little less. For example, with n = 5, our smallest increment is 20% of that baseline reward - a sizeable jump.
    • Are they leaving headroom for the numbers to get bigger later? If they're starting with nTotal = 10000, how many zeroes will they be throwing around by level 30?
    • Are they considering players' psychological perception of the numbers? (e.g. preferring "neat" numbers that are easy to reason about, like multiples of 5 or 10, and keeping starting numbers low in a game where players expect to start weak and get stronger)
  • Are they thinking about how they'll evaluate and tune this down the line?
    • What criteria are they looking at to assess how well these numbers work?
    • Do they have specific workflows for iterating on these values (like a balancing spreadsheet)?

In my own practice, when I've done this kind of balancing in games like Splinter Cell Blacklist, Starlink: Battle for Atlas, and Far Cry 6...

  • I start by choosing a base reward that's a nice familiar number like 100, then seeing where that leads. I'll come back and revise this number later if I find my first choice leads to the wrong outcomes.
    • (I'm not usually working on the kind of RPG where by the end you have 3-5 extra zeros at the end of all your numbers - I might start lower in that case)
  • Next, I'll pick a time horizon for the first level-up / first purchase. For a console action game with RPG elements like the examples above, I usually want players to see their first milestone of progress within the first 20-30 minutes:
    • early enough they get a sense of progression in their first play session, even if they play for only 30-40 minutes...
    • ...but late enough that they have a chance to get a handle on the base action mechanics before we complicate things with progression systems.
  • I'll work out how much reward-granting activity I expect them to do in that time window.
    • Early in development, this will be a guess, like "1 battle every 5 minutes?"
    • As the game content gets built out, I can include in my models the exact set of rewards on the player's golden path or in side activities.
  • I'll adjust the level thresholds to match how much rewards I expect players to get in that time frame (along with where I want them to be at the end of the first hour, at the end of the onboarding section, at the end of the first chapter, at the end of the campaign...)
  • All of this goes into a spreadsheet model, so I can change a number like n or the number of fights in quest 37 in one place, and immediately work out what that does to my pacing or the target XP numbers.
    • I also set up these spreadsheet tools to help me format the data for convenient import into the game engine, and to update the project wiki to keep the team on the same page, while minimizing gruntwork or copy-pasting errors.

    • These spreadsheets start very simple, just automating some multiplication / division or rounding in staging out the XP targets. But as I keep adding to them over the course of a project, they grow into powerful predictors of what impacts our number choices are having, speeding up the iteration loop to dial-in on the right balance:

Progression curves in Far Cry 6

That's not necessarily "the correct answer" to how to pick these numbers. But notice how, if you were an interviewer, you now have a much clearer idea of how I think about this area of design, how I work through problems, and what it might be like to work on a game project with me on the team. That's what the interviewer really wants to know.

For more on interviewing for design roles, I'd recommend checking out Richard Carrillo's GDC talks:

\$\endgroup\$
5
  • 8
    \$\begingroup\$ Very nice. There is also the other end of the question: how important is a single level up? Does it just mean a few numbers go up a little bit without any player input? Or does it mean I have to make some major decisions on how the player wants their character to grow? Do I expect 100s or even 1000s of level-ups during the entire game or only around a dozen? \$\endgroup\$ Commented Jun 26 at 8:48
  • 1
    \$\begingroup\$ It is also possible that the recruiter wanted to know whether the candidate is familiar with the idea of computational complexity - "reskinned" into a problem of how much exp is needed for each subsequent level - the same as for the previous one (linear), twice as much (exponential), the next square number (quadratic) and so on. Both because it's crucial for a developer (to understand the performance of algorithms), but also from a game designer's perspective (too easy vs. too grindy). \$\endgroup\$ Commented Jun 26 at 13:41
  • 2
    \$\begingroup\$ I'd say if they wanted to get at that, they'd ask a different question. \$\endgroup\$ Commented Jun 26 at 13:43
  • 2
    \$\begingroup\$ And as a general rule, this holds true for all job interviews in this kind of industry, not just game development. The interviewer doesn't care about your ability to memorise trivia... they care about whether you're capable of thinking your way through the kinds of problems you're expected to encounter. \$\endgroup\$ Commented Jun 26 at 21:40
  • 1
    \$\begingroup\$ And also checking that you don't freeze up, give up, dismiss, or bluster when faced with situations where you don't know an easy answer. 😉 \$\endgroup\$ Commented Jun 26 at 21:44
8
\$\begingroup\$

This answer is more of less just an expansion to DMGregory's excellent analysis, but I'd approach the topic from the opposite direction:

What does a level-up mean in your game?

You sadly provide very few information to even just the general type of game you're talking about, and that makes a HUGE difference.

For example, the Battlefields and Call of Duty's (as well as most PvP focused FPS) have a levelling system where after the initial 30-ish, the impact of another level-up is mechanically irrelevant. This means that you can let the players level up often and without a limit, the sole consideration for pacing being how often you want that extra reward drop (both item wise but also symbolic). This also allows for a Prestige mechanic, which is basically a meta-levelling system built on top of the regular progression, where what used to be level now basically become XP steps.

At the absolute contrast to that is Dungeons & Dragons with it's PC incarnation of Baldurs Gate 3 capping levelling at a mere 12, with every single level-up having a significant mechanical impact and the mere act of levelling up being a gameplay experience in itself which players can meaningfully spend hours on (in total) pondering over the different options and their implications. This is necessitated by the fact that DnD levels scale exponentially in power so you can only give out so few before you'd need to be fighting gods to keep it interesting, as well as enemies not levelling alongside you, which means that handing out too many levels to quickly (even just one or two) can make the game boringly easy. Exponential XP requirements help here because even killing all enemies in the first area will not overlevel you completely (it will make the game quite easy, but still within reason). Equally impactful are (early) levels in League of Legends. While BG3 levels can take hours, an entire League game rarely amounts to one, so levels have to come in a matter of minutes.

Skyrim "solved" the issue of over/underlevelling by having enemy scaling, which in return massively devalues level-ups and sometimes makes them a detriment to how the game plays, so despite the levels having a far greater mechanical impact than in Battlefield, there's similarily little pressure to gatekeep them.

Enshrouded (though still Early Access with balancing issues) devalued levelling in a different way: You do get meaningful skill points that do boost your damage significantly, BUT the a major part of power progression comes from your gear, which is technically not level-gated in any way and enemies (and more importantly their loot drops) don't scale with you but with the area. [This is also the case in Baldurs Gate 3 but in Enshrouded the relative impact of gear over levels is far greater]

So first you need to make a decision how important levels are going to be.

If you want meaningful levels

you then decide where you want the player to have what level and within which tolerance & up to what limit. Then you see what potentially xp-rewarding action you roughly expect your player to have up to each point, accounting for possible grind or skipping of optional sections / parts. Then you pick arbitrary (nice looking) numbers for the most vital few points, trying to draw a somewhat exponential curve through them. Then you distribute the necessary XP among the stuff that happens in between the last point and the next,If you want to reduce possible variation in levels by a certain point, increase the exponentiality of the curve before it as well as providing a significant amount of unavoidable XP right before it (for example by adding a mini-boss, rewarding a story-quest resolution etc. to reduce the relative impact of grind (or skipping thereof). Btw.: counter-intuitively, it doesn't really have to be a curve. Make it a squiggle if that fits your game progression nicely (which you can combine by having more and less impactful level-ups, like level 6 in League of Legends being far more impactful than 5 or 7, or RPGs having im- or explicit level requirements for power-spike features). If you don't want to meddle with XP progression but still want to give optional rewards, use gear or consumables. XP given once gives a (decreasing but still) permanent power boost, but a nice piece of gear will eventually be outclassed by the next find, meaning that that optional boost can be far stronger (e.g. feel better) without messing with the rest of the game balance.

If you don't want meaningful levels:

Ideally use large-scale data gathering from beta-testers. Start linearly-ish (slightly exponential is always expected) and adjust as feels right. Or if you have the data: as player engagement requires it. Because all your level-up system is here is a small, easily adjustable dopamine boost.

As for concrete numbers in both variants: use what fits your game. Some jRPGs are known for insanely inflated numbers and getting 10xp when you literally dealt 3 billion damage that fight feels wrong. On the other hand, getting a thousand early on when your dagger deals 7 feels out of place too (though xp going into the hundreds is rarely out of place, even BG3 with damage barely hitting double digits for a good while has 300xp rewards on minor fights). There's a whole lot of psychology behind adding technically meaningless zeroes to numbers but that's a different discussion (where I just know that it has a surprisingly large impact)

\$\endgroup\$

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.