Original Post — Direct link
about 3 years ago - /u/Scriptacus - Direct link

Originally posted by DeliciousWaifood

Mate, why would they leave a space specifically for 4 people?

What if they decide to make a mode with 6 people then?

This isn't scalable design, the only thing it could possibly used for is having a single extra person. It's literally just likely to be a leftover from the game having 4 man squads in the testing phases.

And even then, if you want scalable, you wouldn't do it like this. You'd create something in the backend of the UI that changes the size of the UI pieces depending on how many people are in the squad, so it could have as many people as you want and have no weird spaces left over no matter which setting you choose.

You sound like someone who took one lecture on game architecture and now thinks he's an expert while completely talking our your ass and just using buzzwords.

TLDR: /u/Sniper0087 is correct about scalability. Also, Apex was 3 players by design from the start.

Mate, why would they leave a space specifically for 4 people?

The UI indicators are the size they are for a few reasons; the less of the character portrait that is covered by the number the better, and the remaining space covered the most likely case for an LTM or special mode before requiring an additional row or a redesign.

What if they decide to make a mode with 6 people then?

Go vertical, or redesign.

This isn't scalable design, the only thing it could possibly used for is having a single extra person. It's literally just likely to be a leftover from the game having 4 man squads in the testing phases.

It actually is scalable design, not a leftover. A primary driver of the indicator size is too not block the portrait. Secondary is for available space to be divisible by the indicator size. If the portraits had been wider, or rectangular instead of skewed, we would have supported 5 or 6. For example the bottom bar, where you see a players final selection, can handle far more than 4. It may seem like it makes no sense to support 4 in one place in the screen vs. 6-8 in another, but to a developer it means you only need to update one place in the screen to support > 4, instead of needing to update 2. As to why that might be a big deal, see below.

And even then, if you want scalable, you wouldn't do it like this. You'd create something in the backend of the UI that changes the size of the UI pieces depending on how many people are in the squad, so it could have as many people as you want and have no weird spaces left over no matter which setting you choose.

With unlimited time and resources you might do something like that (and you're assuming that spacing is the most important goal, which it wasn't). In actual game development you have to find the balance between scalability vs time/effort. The UI isn't web based or made with standard tools, it's proprietary, and something that seems simple may be significantly more time consuming than you would imagine. You design within the constraints and plan for future scaling as best you can.

about 3 years ago - /u/Scriptacus - Direct link

Originally posted by DeliciousWaifood

Im not attempting to read a comment with formatting that shit.

But you already did :)

about 3 years ago - /u/Scriptacus - Direct link

Originally posted by DeliciousWaifood

Go vertical, or redesign.

Exactly. If you need to redesign it in order to change scales to any significant degree, then it isn't scalable design.

It actually is scalable design, not a leftover. A primary driver of the indicator size is too not block the portrait.

Ok, sure, it could be not to block the portrait.

That isn't scalable design, that is just trying to make the UI unobtrusive.

Secondary is for available space to be divisible by the indicator size.

Ok, so it just happens that it turned out to be able to fit 4 number cards in there before they would be too small. That's still not scalable design when the only scalability is an increase of 1 before having to redesign.

It's just a convenient little extra left over from other design decisions.

like that (and you're assuming that spacing is the most important goal, which it wasn't). In actual game development you have to find the balance between scalability vs time/effort. The UI isn't web based or made with standard tools, it's proprietary, and something that seems simple may be significantly more time consuming than you would imagine. You design within the constraints and plan for future scaling as best you can.

Except that they've already done basic UI element scaling in the game.

  1. In duos, the bottom bar is filled entirely with two players. The nameplates get scaled up or down to fill out the bar depending on the number of players.

  2. Red shields have their shield pips scaled down so that the overall bar is the same size as a purple shield bar.

They are by no means incapable of scaling elements to fit requirements.


The bottom nameplate bar is set up to be scalable to a decent degree with the width of the nameplates dynamically changing.

The legend portrait area is set up to be scalable to a great degree, since they planned to add more and more since the start.

The numbers on the portrait really aren't scalable, there is just one single little space left over that may come in handy, but hardly counts as being scalable design.

It was as scalable as it needed to be, given that to date more than 4 indicators have never been needed. When you examine the purpose of the indicators, which is to convey intent in a "one legend per squad" environment, the range of up to 4 covers 2/3rd's of the possibilities; players start with only 6 legends unlocked and you need to handle the case of a full squad in that state. Any more players than that and the "one legend per squad" restriction no longer works.
Spending effort to support 5 and 6 man squads wouldn't have been worthwhile.

Your assumptions about "basic UI element scaling" aren't correct; there are quirks and intricacies to RUI (the proprietary system used to make most widgets in Apex) that you're not aware of. For better or worse, systems like RUI are designed to functional and extremely performant before being unified and easy to work with like most web standards. Even something as simple as passing in an additional integer might push a complex widget (which the portraits are) beyond the maximum parameter count. Different designers worked on different widgets and menus, and they're often built in completely different ways. Some widgets use actual skewed rectangles, others use a series of baked images of the exact size needed, while others use rectangles with right/left end caps. It all depends on who is implementing it, what assets they're given by the UI artist, how much time is available, and even when that time was available. Sometimes work is done in a less than ideal way because those were the only capabilities at the time. When new tech comes online you don't automatically go and refactor/reauthor things that are already working, as that is time that can be better spent adding new things to the game.

TLDR; making games is more complex that you think

about 3 years ago - /u/Scriptacus - Direct link

Originally posted by DeliciousWaifood

It was as scalable as it needed to be, given that to date more than 4 indicators have never been needed.

Then it's not scalable. The point of scalable design is to have a system that is flexible enough to allow you to scale up your system beyond what was previously needed.

If you design the system to just be "enough for now" then that's literally just regular design, it's not scalable.

When you examine the purpose of the indicators, which is to convey intent in a "one legend per squad" environment, the range of up to 4 covers 2/3rd's of the possibilities;

This doesn't make it scalable design.

Spending effort to support 5 and 6 man squads wouldn't have been worthwhile.

Sure, I'm not saying they needed to do it. I'm saying it's not scalable design.

The squad dropping is scalable in that it seems like it can handle any arbitrary number of players simply by adding them into a V formation. It could handle 4, or 6, or 12 or so it would seem. That is scalable, this UI element is not.

Your assumptions about "basic UI element scaling" aren't correct; there are quirks and intricacies to RUI (the proprietary system used to make most widgets in Apex) that you're not aware of. For better or worse, systems like RUI are designed to functional and extremely performant before being unified and easy to work with like most web standards. Even something as simple as passing in an additional integer might push a complex widget (which the portraits are) beyond the maximum parameter count. Different designers worked on different widgets and menus, and they're often built in completely different ways. Some widgets use actual skewed rectangles, others use a series of baked images of the exact size needed, while others use rectangles with right/left end caps. It all depends on who is implementing it, what assets they're given by the UI artist, how much time is available, and even when that time was available. Sometimes work is done in a less than ideal way because those were the only capabilities at the time. When new tech comes online you don't automatically go and refactor/reauthor things that are already working, as that is time that can be better spent adding new things to the game

I don't see how any of this proves that it is scalable design. You're just giving me justification as to why they would choose to not make it scalable, which is besides the point.

You really seem to have completely missed the point here, mate. I've never once been arguing that they should change the system they are using, I'm just saying it's not scalable, which it is not.

The point of scalable design is to have a system that is flexible enough to allow you to scale up your system beyond what was previously needed.

It literally does that. As stated earlier the design scales vertically (not ideal for visuals, but perfectly functional) to handle up to 12 players (which is still 6 more than would ever be required), which is the same number you've used above to deem the V formation as scalable.