#math effect

The answer is both yes and no. As we get more of a particular thing, it almost always naturally pans out as a bell curve distribution. That means that, as you get more of it, you'll find more and more extreme examples, while most of the things (~68%) will fall within one standard deviation of the mean.

What this generally means is that, as we get more Unreal Engine games, we'll see some really amazing stuff at the top end (> 2 standard deviations from the mean) that we never would have seen before as a small number of dev teams go above and beyond to eke out things not thought possible before, and a whole lot of really mid stuff.

I believe this observation tracks with most popular media for consumption in general - most stuff is mid, with the really good stuff being a fairly small percentage of the total offerings of the market. Whether it's games in general, Unreal Engine games, books, movies, television, or whatever else, the bell curve tends to hold true as the total number of offerings increase. Teams that use Unreal Engine will tend to gravitate toward what Unreal Engine is good at and avoid what Unreal Engine isn't good at. Some will push boundaries and a small number will hit it out of the park. Don't judge a platform, a toolset, or tech by what the mid result is, judge it by the best results they have.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

We don't really have hard limits per se, but we have guidelines we try to follow. What you're talking about is a power curve which, in game design, describes the way that game elements grow in power over the course of the game's advancement systems. It is rare for a game to have items that are always obtainable from start to finish; usually there is some sort of progression from early game to mid game to elder game with growth in power along the way. The amount of growth and amount of resulting power is usually some sort of math formula, with small independent tweaks here and there to increase interest and fun. Usually this is a formula that takes some sort of resource cost or requirement (e.g. level, mana cost, gold cost, drawback, etc.) and converts it into some sort of desired result (damage, stat boost, good effect, etc.).

System designers take the costs and the desired results and create a formula to calculate one from the other, based on how we want the items at that power level to play. As an example, in Hearthstone minions that cost one mana have a rough ceiling of some established power. Minions that cost two mana have a higher power ceiling, minions that cost three mana have even higher, and so on and so forth. This is our baseline power curve - the guidelines that we use to generate our first pass for stuff. We establish a band at each cost for acceptable power - a low end and a high end, so that we have a means of measuring items that are too strong for their cost and items that are too weak for their cost. The floor is typically pretty low, really weak items generally don't cause gameplay problems like overly powerful items can.

We then add in modifiers like rarity (e.g. a three-cost legendary minion is better than a three-cost common minion) to adjust the power level of the individual items. We can add in interesting procs, beneficial effects, drawbacks, or whatever at this point. Each of these benefits or drawbacks has a power budget associated with it we use to determine its position within the power band. We can adjust these budgets to make certain options better or worse at our discretion, with the goal of staying within the acceptable power level band.

We then playtest our work to see how our numbers and power levels actually feel. We take our observations, iterate and adjust the numbers, and then playtest again, repeating the cycle until we get our desired play experience at each power step and level.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

The reason we don't do it is because our eyeballs perceive things in perspective, not orthogonal projection. The believability of a perspective projection is much higher for the same reason that games feature humans and humanoid characters - it's what we're used to and comfortable with. A constant orthogonally projected view would get really weird after a while.

The closest we get to true orthographic projected cameras is in the isometric 2D sprite-based games like Sim City, where we didn't actually do 3D rendering, so a perspective view was impossible. It looks fine in a stylized visualization, but seeing it more realistically rendered would cause a sense of unease in the viewer, due to the expectation of a perspective view.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

System designers manage difficulty curves. It is up to them to tweak numbers and timing in order to make sure difficulty feels good along the way. They work primarily within formulas and spreadsheets in order to keep things predictable for the general experience (normal moment-to-moment gameplay), and adjust individual elements of special encounters for a more hand-tailored high impact result (e.g. boss battles).

The formulas are how we scale difficulty are primarily for two factors - how long it takes to finish the encounter, and how much danger we expect the player to be in during those encounters. These two factors are broken down into several different sub-categories - damage, damage avoidance, damage reduction, accuracy, time per attack, etc. We can tweak each of these factors to adjust play experience while maintaining a cohesive overall whole. An encounter that feels dangerous will have higher spike damage, while an endurance battle will take longer. We use the formulas to establish a baseline, then tune the individual encounters we want accordingly. This creates an expected experience band for players, which we verify through playtests.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

Nah. Trying to do this basically results in hopelessness because there's no end to it where you need to design a couple hundred new and different cards every year. It's such a combinatoric explosion and there are so many potential interactions that it quickly becomes an unsustainable mess. It's generally better to look at how things work and adjust as you go, since there's just too much complexity for any single designer (or even design team) to know about. You do your best and you adjust as you go. That's the best you can really hope for.

Let's also be clear - Wizards of the Coast didn't ban Vein Ripper at all. Vein Ripper is still legal in every format. WotC banned Sorin Imperious Bloodlord in the one format (Pioneer) that they felt it was overpowered (and Explorer, the online-only format version of Pioneer), because nobody cares if a 6/5 flyer comes down for "free" on turn three in Modern or Legacy when even a 20/20 indestructible flyer two-card combo on turn two isn't strong enough. In this kind of situation, Sorin was the combo enabler and Vein Ripper was just the nastiest free vampire that was in the format for Sorin to drop. Banning Vein Ripper would only be a temporary measure until the next big nasty vampire entered the format that could drop on turn three.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Short questions: Ask a Game Dev on BlueSky

Long questions: Ask a Game Dev on Tumblr

There's no way for a single user to do it by herself in that case. The best means of approach is to collect aggregate data. Since unopened loot boxes are fungible (i.e. all loot boxes are functionally equivalent until opened), it doesn't matter if one person opens a thousand loot boxes or a thousand people open one loot box apiece. Thanks to the combined powers of statistics and math, we can calculate the sample size we would need for an average result at a given confidence level and interval step.

Mathematically, I believe we expect a sample size of ~381 draws to have a 95% confidence rate and an error margin of +/- 1%. The more precise we become, the higher the necessary sample size becomes (e.g. a 99% confidence rate with an error margin of +/- 1% requires around 660 draws). If players tracked and aggregated all of their combined results from the same loot boxes, they could run statistical analysis on them and see whether the results lined up with the posted odds.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

Some readers may not realize it, but you're actually asking a math question here. A bit is a value that can be one of 2^1 = two different values - 0, or 1. Thus two bits can represent up to 2^2 = four different values - 00, 01, 10, and 11. Three bits can represent up to 2^3 = eight different values - 000, 001, 010, 011, 100, 101, 110, 111. 10 bits can represent up to 1,024 different values, 16 bits can represent up to 65,536 different values, 32 bits can represent up to 4,294,967,296 different values, and 64 bits can represent up to 18,446,744,073,709,551,616 different values.

As you can see, 64 bits has a much larger range of potential than, say, 8 bits. However, just because it can store a lot of different values doesn't mean that you want to use 64 bit values everywhere. Imagine that I'm working on a game that has committed to four playable races - dark elf, hot elf, keebler elf, and santa elf. If I used a 64 bit value to store the player character's race, I'd wasting a large amount of that usable space - I really only need two bits to represent the four different possible races on a character so I would essentially wasting 62 bits of memory to store that one value. However, locking myself in to two bits for the player character race means that I'm also committing to never adding a fifth supported race (e.g. hers elf) for the lifespan of the game, because I would need additional bits to represent the fifth race. If I were forward-thinking, I might split the difference and give myself four bits (16 total races, room for up to 12 additional races) for the lifespan of the game.

Your question topic is known in programmer space as "bit packing" because the most efficient solution is to use the fewest number of bits possible to store the data. This way we don't waste computing resources that could be utilized elsewhere. A lot of clever engineering is about utilizing facts we know about the game's design (like the number of supported player races) and using that to shave down the needed bits to represent the data. This usually results in immediately improved performance and problems down the line if the game continues for years and the old assumptions get broken (which is often what happened when many old live service games needed to convert from [32 to 64 bits]).

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr

You can figure out a vector distance pretty fast if you use the dot product. The dot product of two vectors A and B is the Length(A) x Length(B) x Cos (angle between them). If you dot a vector with itself, then you get Length(A) x Length(A) x Cos(0). Cosine of zero is one, so any vector A dotted with itself is Length(A) squared. If we're doing a comparison, we can take the distance threshold, square it, and compare it to the dot product of the vector from the camera to the object and itself.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Short questions: Ask a Game Dev on Twitter

Long questions: Ask a Game Dev on Tumblr