A Modest Proposal: A Bridge Server System for Reliable Player Progression and a Better Skill Curve

NousWandererNousWanderer Join Date: 2010-05-07 Member: 71646Members
edited November 2018 in Ideas and Suggestions
TL;DR
This proposal outlines a modified quickplay option that would use predetermined server configurations to represent "tiers" of a skill-progression system. It isn’t matchmaking. It doesn’t de-whitelist or unrank existing whitelisted servers. It would likely require a modest improvement over current player retention rates (+100-150 players) BEFORE being attempted. Although it could be accessed via quickplay, it could also be accessed via the server browser (provided that you are the appropriate skill level to join a particular server).

These tiers would be skill-bracketed so that players hopping from one tier to the next can have a reasonable degree of confidence that they won't get stomped by pub gods. Instead, these players will be competing against players of comparable skill at each step. This system would provide utility to both low skill and high skill players who seek games better suited to their respective abilities. Maximum playercount tapers down as the tiers progress up in skill.

Skip to the section titled "An Alternate Approach: The Bridge System" for additional details.



CONTEXT
UWE is working on a roadmap as part of a new development cycle set to culminate in a marketing push for “NS2 2.0”. Quote: “This isn’t a new game, but what we feel is the ultimate version of NS2. Once our objectives on the roadmap have been completed, we will work with our partners to do a large marketing push and even test some free to play options to get NS2 in the hands of those who haven’t had the opportunity to play.

Given the resources still being devoted to Natural Selection 2 this long after its release, I assume that this marketing push will be a litmus test which will determine if ongoing development is financially viable (e.g. minimally self-sustaining) for the company. My proposal is being offered in that context. My chief considerations are the skill curve and player retention, which I view as related.



ROADMAP SCOPE & A DEEPER CHALLENGE
The roadmap presents key improvements that would modernize the game in crucial ways relevant to the rookie experience:
These changes are positive steps. But they do not adequately address one of the most fundamental issues Natural Selection 2 faces, and I am not convinced that they will alter the new player’s experience in a way that radically improves player retention over the long term.

Player retention is the big challenge. This isn’t news. We’ve been told that sales aren’t the main issue; the current development team’s salaries are paid for on the basis of ongoing game and cosmetics sales. The trend seems to be thus: players buy the game, experience it for 8-10 hours, and then retention drops off precipitously. The few players who stick around continue to improve and often become dedicated fans. Unfortunately these players are a small percentage of those who make the attempt. You can view monthly averages here.



THE SKILL GAP
NS2’s skill gap isn’t a problem in itself. It’s a byproduct of the game’s depth and skill ceiling. Nonetheless, the gap produces challenging secondary problems when paired with our shrinking playerbase.

NS2’s gameplay isn’t going to become significantly easier to adjust to in the near future. Steps can be taken to better inform new players of the game’s mechanics, yes. But the skill ceiling is very high, the game has complex mechanical input requirements, and there are currently many high skill players who’ve spent thousands of hours near the top of that ceiling. Populated, fast servers with good ping are limited, so the small number of concurrent players (of wildly different skill levels) are compressed into the same spaces. You know the story.

Rookie servers are woefully inadequate at addressing this reality; they’re only useful for familiarizing players with the very basics. In many respects they prepare players for a version of the game that isn’t experienced anywhere outside of those servers: a slow, confused, unresponsive experience.

Gameplay is the hook. NS2’s gameplay is complex and rewarding. But many players never experience this depth because they’re thrown into the shark pit and devoured alive before they learn to swim. Advanced skills like strong gamesense are pipe dreams for these players.

You can’t put a bandaid on this. If you want to retain players, they need to observe a progression in their own skills. This is felt experience; no amount of external signalling is going to compensate. Awards, trophies, stats, indicators, ui/ux improvements - all good steps. A progression system can reward a player for earning points or playing a certain number of hours, but what it can’t do is actually make a player better. Only time and practice can do that.

But who has the time for such brutal practice? Most players don’t want to spend time practicing a low-population game dominated by superfreaks who move at the speed of sound and shoot 35% on the regular. Imagine if you first learned to ride a bike at the age of 4 by being thrown into Olympic road cycling races. At worst there’d be a bunch of kid smears on the pavement. At best a majority of the kids would swear off competitive cycling forever. Sure, some small percentage of hardy challenge-seekers might keep pedaling, but how many? Not enough to grow the sport, certainly.



MATCHMAKING?
A functioning matchmaking system could be gold. Unfortunately it would also require a massive increase in concurrent playercount (estimate: upwards of 1000 players). That’s such a large increase - an increase that’s contingent on so many other factors - that it’s almost not worth considering. We could spend time outlining what the ideal matchmaking system might look like, but implementing one anytime soon isn’t likely.

Matchmaking represents a step far beyond merely grouping players together and pushing them into an existing community server (which is what the already ambitious ‘match seeding’ card purports to accomplish). With matchmaking, we’re talking about using an algorithm to build balanced teams from the online player pool, pushing those teams into a competition (not a ready room), penalizing leavers, and so forth. It’s a more complex system by design and is ultimately a gamble. What happens if, post-matchmaking, playercounts begin to decline again, and the seemingly functional matchmaking system starts producing games that are of lower quality than those naturally produced by hive balance alongside the current community server ecosystem? There’s no coming back from it. And nobody wants to experience massive wait times simply to play a balanced game.

I can envision a miserable future where the wait times are so long that the games never happen and/or the threshold for balance is increased so broadly that the outcomes (in terms of team composition by skill) are abysmal. True matchmaking is to be considered when a game is thriving. Natural Selection 2 is far from thriving. We have to recognize that our community server system offers key advantages at our current scale, even as it offers key disadvantages. The task is to devise a system that is both compatible with the current paradigm but which reliably offers a more reasonable experiential progression curve that players are currently denied.



AN ALTERNATE APPROACH: THE BRIDGE SYSTEM
Bridge seeks to use NS2’s current server-based approach to provide both rookie and veteran players with a reliable way to join games versus opponents of reasonably appropriate skill. Rather than requiring a great deal of code, Bridge attempts to leverage existing systems in order to produce better outcomes. These systems include: hive, quickplay, and community servers.

It would work as follows:
  • Add a new button called ‘Bridge’ beside Quickplay OR add a checkbox called ‘Bridge’ next to the existing Quickplay button (which would modify your quickplay selection accordingly - e.g. you'd only be quickplay-joining Bridge servers if you've checked the box).
  • After clicking the button, you’re brought to a skill-bracketed server with other players. These are normal servers subject to the ebb and flow of players joining and leaving, just like any others.
  • You can also join the server manually via the server browser. Because the Bridge servers would be skill-bracketed, you’d only be able to join if your hiveskill is within the appropriate range.
Using the values below, Bridge servers would come in four different flavors or “Tiers”. Each tier is described as a unique server configuration. Four server configurations for four tiers. UWE would define these configurations internally, tweaking the values as needed.

The following numbers are for illustration only. The final values should be better informed using the best data currently available. These are merely spitball values I produced while mapping out the idea. They’re based on my assessment of the frequency with which players of various skill levels play the game, and of what "tolerable" skill ranges would be for developing players:
  • Bridge Server Tier 1: (12v12) 0 skill to 1000 skill
  • Bridge Server Tier 2: (10v10) 800 skill to 2000 skill
  • Bridge Server Tier 3: (10v10) 1800 skill to 2800 skill
  • Bridge Server Tier 4: (8v8) 2600 skill minimum

This is a skill-bracketed system: not a revolutionary idea. The simplicity is by design. I firmly believe that more complex systems are unnecessary to produce the most immediately valuable outcomes in the short term. I also believe that unless some type of progression/retention pipeline is established, UWE risks spiking the playercount (via their roadmap efforts) only to see it decline once again.



BRIDGE PLAYERCOUNTS
Playercount tapers from one tier to the next because newer players benefit from having less personal responsibility as they acclimate to the game, and high skill players benefit from having more. 8v8 also represents a more authentic version of the game’s original vision.

Further, there are likely to be more new players than veterans at any given point. This helps with seeding.

6v6 competitive is one step above it (and could be supported in-game via an additional tier or a built-in gather system). I’m not including it in this proposal’s scope.

Note: if UWE ever decides to place a hard cap on whitelisted playercount (e.g. only 8v8 to 10v0 servers are whitelisted), then simply constrain or eliminate the playercount tapering accordingly.



BRIDGE SKILL TIERS, OVERLAP & HIGH SKILL PLAYERS
The skill ranges were selected to provide meaningful and impactful brackets (re: gameplay) without excessive granularity (that might result in poor seed rates). The overlap is intended to provide most 'borderline' players with two options as they transition between tiers, and to make ranking down/up less frustrating.

Just as tiers 1-3 would provide obvious utility to developing players, tier 4 (top tier) would serve as a de facto gather system for the high skill players. With a single click, they could be brought to a server where every player is above a skill threshold. This reduces stompage elsewhere, albeit indirectly.



BRIDGE LAUNCH INFRASTRUCTURE REQUIREMENTS, SCALABILITY & COMMUNITY SERVERS
A minimum of one server per tier would be required at launch. Because UWE would set the number of tiers and the corresponding server configurations, they could experiment with deploying this system in stages if necessary. Because the tiers are described as server configurations, it would be easy enough to identify which tiers require more infrastructure at any point in time.

It would make sense for UWE to cover the cost of the initial servers. Estimates on rental prices range wildly depending on who you ask, but consensus among community operators seems to be that capable server costs have dropped significantly since NS2’s launch. Server improvements will hypothetically reduce this cost further.

To offset this financial obligation and to allow for easy scalability, community server operators would be given the option to opt-in to the bridge system. Servers which meet the requirements and opt-in would be added to the available Bridge pool. Server configuration variables would include: whitelisted mods, server size, skill range, performance/ping.



BRIDGE VS. NORMAL WHITELISTED SERVERS
Normal community servers that are currently whitelisted would remain whitelisted. Bridge servers would also be whitelisted. You could gain rank on bridge servers or any other whitelisted server. Unlike true matchmaking - which usually entails some stark divide between “ranked” and “unranked” - no significant changes would be required in this regard.



ON THE TOPIC OF COMMUNITY SERVER OPERATORS
It’s possible that the introduction of this system might upset certain community server operators. And it’s true that Natural Selection 2 owes a wealth of gratitude to the server ops who currently provide us all with places to play. Quickplay currently directs players to many of these community servers. This helps keep the servers seeded.

Quickplay would function the same way post-Bridge. There’d just be a new option for players who want to filter into Bridge servers because they’re seeking a place to develop their skills first and foremost. This may provide a quality of play that is desirable. And in turn, this may effectively become a form of popularity “competition” for extant server communities (see next section for more on this). Can we risk that? First we have to ask ourselves: is the current model working? My attitude is that it isn’t working. It’s life support. Something has to change.

It also isn't clear that the competition would be destructive. Many of us participate regularly in beloved server communities, but there are tens of servers which see 0 traffic. Please uncheck ‘empty’ and take a look at your server browser the next time you refresh. Surely some of these perform well. Opting into the Bridge system would offer a way for some of these server operators to get more value out of their investments at a minimal challenge to the existing community paradigm. This might be seen as “doing UWE’s work for free” but I am not convinced that it’s the case. Server operators each have their own motivations and aren't a monolithic group, so I would rather not generalize further about what they will or won't do should a system like this be implemented.



CAVEATS & A NOTE ON TIMING
Bridge aims to improve player retention, but it also requires that the average concurrent playercount increases first. This is NS2’s Catch-22: we need more players for player-retaining systems to work in the first place. But unlike true matchmaking, a Bridge system would require only a moderate increase in playercount in order to populate a minimum of four servers. I guesstimate a retention increase of around 100-150 players above the current average would be sufficient. This seems more than achievable via the roadmap and a marketing push.

As such, my recommendation is as follows:
  • Complete a majority of the items on the roadmap. Prepare for the marketing push.
  • Smurf protection: initialize new family sharing accounts at the highest hive skill value associated with the main account. I was watching a NS2 streamer smurf in a rookie server the other day, but unfortunately he encountered 3 smurfs on the enemy team. Surprise! Smurfing is perhaps the Bridge system’s biggest vulnerability and the single roadblock that would prevent the system from offering the gameplay experience it advertises, so this change would be prudent.
  • Concurrent with the rebranding/remarketing of the game, introduce the Bridge system as a retention net / progression pipeline. Be sure this is in place before playercount spikes.
  • Be sure to explicitly inform new players of this option’s existence as part of the push, perhaps via a paragraph w/ a few lines in the inevitable marketing email, and as a pop-up for new players who load the game for the first time, and for old players who make a return.
  • BONUS: come up with a unique badge or cosmetic that is somehow tied to Bridge server participation.
Thanks for reading. Adios.









Comments

  • NokyNoky Join Date: 2010-04-10 Member: 71295Members, NS2 Playtester, NS2 Map Tester
    I agree with this completely; however, if the queue system is too long, no one will use the bridge feature. I still think it is worth it, because quickplay is... not performing to current standards. Unless you believe that NS2 should be played with bots and not humans.


    Additional thoughts:
    If using bridge could also make pairing with friends possible, then I think it would help with player retention. You probably didn't include this because the system is, already, a lot to take in. I know it's complicated when factoring in ELO, but at least for some rookies looking to play the game, this opportunity should be available. I believe being with friends is an important feature to a game. That is what will create fun memories.

  • NousWandererNousWanderer Join Date: 2010-05-07 Member: 71646Members
    edited October 2018
    eclipszor wrote: »
    I agree with this completely; however, if the queue system is too long, no one will use the bridge feature. I still think it is worth it, because quickplay is... not performing to current standards. Unless you believe that NS2 should be played with bots and not humans.

    Additional thoughts:
    If using bridge could also make pairing with friends possible, then I think it would help with player retention. You probably didn't include this because the system is, already, a lot to take in. I know it's complicated when factoring in ELO, but at least for some rookies looking to play the game, this opportunity should be available. I believe being with friends is an important feature to a game. That is what will create fun memories.
    Thanks for the reply.

    Queues: As I'm envisioning it, the only time there would be a queue would be when every available slot on all tier servers are taken (that is to say: the tier servers that correspond with your particular skill level). The system wouldn't be establishing teams or anything like that; players would still be using hiveskill + shuffle to produce good rounds within the server itself. If queue times do get out of control, that would serve as an indicator that certain tiers need more servers deployed. So at least the system would have the ability to scale up with popularity. This is probably not a hugely relevant concern at our current playercount, because right now we don't have enough concurrent players for this system to work reliably. But your point is well taken.

    Playing With Friends: I'm not sure how the Play With Friends feature will function. UWE is developing it separately from any potential Bridge implementation. I suspect that it'll involve small groups of friends (2-4) lobbying together via a menu option, and then being quickplayed directly into a server together. Some mechanism will need to communicate with the server in order to preserve these friend "groups" even when shuffle happens, which means that UWE will have to put a lot of thought into what the limitations are.

    For example, if three players with 5k hiveskill group up, that's going to significantly impact balance on whatever server they get placed on. But assuming that UWE figures out a way to iron out all of those general issues, I don't see why it wouldn't be possible for friends using this system to choose to be quickplayed into a Bridge server. Same principle as above: an additional checkbox or button to indicate that you want to join a Bridge server and not a normal whitelisted server. The main requirement would have to be that all players in the group are within the appropriate skill range for the same tier. If they weren't, they'd have to get a warning message when attempting to queue.
  • NokyNoky Join Date: 2010-04-10 Member: 71295Members, NS2 Playtester, NS2 Map Tester
    edited October 2018
    Queues: As I'm envisioning it, the only time there would be a queue would be when every available slot on all tier servers are taken (that is to say: the tier servers that correspond with your particular skill level).

    We don't want to load people into empty servers or half-empty servers and make them wait for others to queue. That will make them leave and go to server browser. There has to be some sort of queue to put someone into an optimal ready-to-go state of the game. NS2 relies heavily on having a full team.


    Three additional thoughts.

    (1) Dying servers often happen on NS2. We wouldn't want this system to re-queue people who just left a specific server to a server they intentionally left. I find this problem a lot on CS:GO. I will leave a server, because I am not having fun on that server, and then I get re-queued back into the same server. This typically leads to me going on server browser. The reverse might also happen; you get disconnected from a server, and then want to quickly rejoin. I guess this could easily be fixed by a "rejoin last server" button.

    (2) It sounds like you don't want Bridge to take over playing NS2 entirely, but your system heavily relies on the population of the game. If your feature was only used by 25% of the population, would that be enough? This system is somewhat related to a ranked system, and not everyone is going to use it.

    (3) I think this system could work solely on the fact that you want to give achievements/progression awards for players using the system. The only reward system we currently have is the commander icon (earned after x amount of games as commander), and the bronze/silver/gold/shadow icon from the skulk challenge. What direction should it take? Most games use lootboxes, or their own currency to purchase items from the store.
  • NousWandererNousWanderer Join Date: 2010-05-07 Member: 71646Members
    edited November 2018
    eclipszor wrote: »
    We don't want to load people into empty servers or half-empty servers and make them wait for others to queue. That will make them leave and go to server browser. There has to be some sort of queue to put someone into an optimal ready-to-go state of the game. NS2 relies heavily on having a full team.
    This is a valid concern, but quickplay already takes into account the number of active players on a server before deciding where to place a player. That same principle would be applied here, albeit limited to Bridge servers when that option/filter is selected. Depending on a player's skill level, they might even be placed into a Bridge server when using Quickplay even when the Bridge option isn't selected, assuming that the other criteria the current Quickplay algorithm uses are satisfied by the Bridge server the player is being sent to.

    To achieve what you describe, NS2 would require a far more robust matchmaking system that builds actual teams and then matches them (with penalties for leaving, etc.). But assuming that no such system is forthcoming, players will always be rotating in and out of servers under normal conditions, just as they do now. Servers will sometimes be half-full. Bridge's goal would be to provide these players a quick and seamless way to be pushed into high-performing servers that are skill-bracketed. Because these servers will still be accessible from the server browser (more info later in post), they'll still see a trickle of players who join normally, and that will help with keeping the servers seeded. This can be further augmented by giving these servers "top billing" depending on how UWE organizes the ui/ux and the updated server browser (new menus are being developed).

    The best we can do otherwise is something like the match seeding system which is already on the docket. But, again, I think this would still be compatible with Bridge in the same way that the "Play With Friends" feature would be.
    eclipszor wrote: »
    (1) Dying servers often happen on NS2. We wouldn't want this system to re-queue people who just left a specific server to a server they intentionally left. I find this problem a lot on CS:GO. I will leave a server, because I am not having fun on that server, and then I get re-queued back into the same server. This typically leads to me going on server browser. The reverse might also happen; you get disconnected from a server, and then want to quickly rejoin. I guess this could easily be fixed by a "rejoin last server" button.
    This is a valid concern. The good news is that the system I've outlined is completely cross-compatible with the server browser. You could actually bypass the quickplay/bridge button altogether and just go to the server browser every time, picking your favorite bridge server from the available options. There are currently filter checkboxes for: full, empty, passworded, bootcamp, unranked. It would be easy enough to add one for 'bridge'. If that happens, it would be good to have an additional column in the server browser indicating which tier a bridge server is (e.g. T1, T2, T3, T4).

    The only conceptual limitation is that you wouldn't be able to join the server if your hiveskill was outside of the corresponding range for that tier. But that also applies to using quickplay to join a bridge server, so it's the same thing.
    eclipszor wrote: »
    (2) It sounds like you don't want Bridge to take over playing NS2 entirely, but your system heavily relies on the population of the game. If your feature was only used by 25% of the population, would that be enough? This system is somewhat related to a ranked system, and not everyone is going to use it.
    It's definitely population-dependent. I estimate that we'd need an additional 100 to 150 concurrent players above the present average to keep bridge reasonably populated at all times. That's why I strongly advocate that a system like this should be put into place alongside the marketing push. It's a less demanding system than true matchmaking would be, but it still requires a well-timed implementation so as to avoid damaging the current community server-based ecosystem. The goal is for both of these systems to work alongside each other.
    eclipszor wrote: »
    (3) I think this system could work solely on the fact that you want to give achievements/progression awards for players using the system. The only reward system we currently have is the commander icon (earned after x amount of games as commander), and the bronze/silver/gold/shadow icon from the skulk challenge. What direction should it take? Most games use lootboxes, or their own currency to purchase items from the store.
    Just to be clear: although it's meant to aid player "progression", the system I've outlined is distinct from progression systems which use things like badges, experience levels, end-of-round stats, awards, and other unlockables to reward players for their play. I completely agree that those systems are good for the game, and they should be discussed in greater depth, but probably outside of this thread. The developers do have a card for a progression system on the roadmap (in addition to other, similar cards). I'm excited to see what they come up with.

    When I use "progression" in the context of this particular idea, I refer more to actual skill development. Because the tiers are skill-bracketed, the goal is to provide players with a "smoother progression" as they skill-up. They currently face an almost vertical uphill climb after exiting rookie servers, so this system smooths that out considerably. But there's no reason that the other systems you describe couldn't be in operation at the same time; they ultimately achieve a different if related goal.

  • NordicNordic Long term camping in Kodiak Join Date: 2012-05-13 Member: 151995Members, NS2 Playtester, NS2 Map Tester, Reinforced - Supporter, Reinforced - Silver, Reinforced - Shadow
    edited November 2018
    This sounds like officially supported skill segregated servers. If that is a correct interpretation, do you really think that official support will actually make it work when skill segregated servers have always been incredibly difficult to seed without official support?

    A better way to ask that question might be, would official support be enough? I don't want to sound like I don't like this idea.
  • NousWandererNousWanderer Join Date: 2010-05-07 Member: 71646Members
    Nordic wrote: »
    This sounds like officially supported skill segregated servers. If that is a correct interpretation, do you really think that official support will actually make it work when skill segregated servers have always been incredibly difficult to seed without official support?
    We'd be banking on the increased concurrent player average prerequisite, the relatively low player slot count at the time of deployment, and the ease of joining using the proposed methods. Obviously some ui/ux/communication efforts would be needed to ensure players are aware of the option, what it does, and how it can help them.

    It's also easily scalable as proposed, so it could be deployed in stages if absolutely necessary.
    Nordic wrote: »
    A better way to ask that question might be, would official support be enough? I don't want to sound like I don't like this idea.
    I think so, assuming it's deployed more or less in the way I described.

Sign In or Register to comment.