Team Shuffle

[Highlink]

I think a vote option to shuffle teams at the end of the match would be good for overall server health. The last few times I've been on one team has been winning every single match and it gets real old real fast to be on a losing streak in this game.

[AshbyJones]

AGREED--today is one of the bad days....out of many bad days.  It's at the point where it's not that one team just happens to work together better or has better players--it's a function of the game being broken.  It's not ppl switching teams...its how the teams are constructed from the start of each match.  What are the devs doing to fix the team balance?  I hear that a while back FairPlay tried to implement some measures to help fix this long-term problem and were prevented by the devs.  Is this true and why?

[Guest Akai™]

Agree full too. Todays night games where all stacked. It was like 8 or 9 games in a row with hard stack where games ended in 20 minutes.  I think ist a big Problem for new players. They are getting totally destroyed cause the new ones are all in one Team and have therefore no fun in the game. There is the leaderboard in this game. Is it not possible to balance games using the leaderboard ? 

[AshbyJones]

Today two developers told me that there is currently no mechanism to balance teams between matches.  I didn't know this--I just thought whatever did exist did not work properly.  One said it just isn't possible...  I have no business developing/coding anything, but it's very surprising that there is no way to measure points/vp/rank/etc. and use that information to sort teams.

I was also told that I have no idea what the Fair Play situation was, which is totally correct.  I do remember when Fair Play had a measure to prevent ppl from switching teams for a certain period at the beginning of matches.  I was told that "the developers" told Fair Play that they could not do anything like this, or their server would be de-listed from the launcher.  Again, I don't know the situation, and I'm no pillar of the community, but I don't understand why balance-related measures can't be experimented with on a per-server basis if the developers say they are unable to do anything about it themselves.

[NodSaibot]

26 minutes ago, AshbyJones said:

Today two developers told me that there is currently no mechanism to balance teams between matches.  I didn't know this--I just thought whatever did exist did not work properly.  One said it just isn't possible...  I have no business developing/coding anything, but it's very surprising that there is no way to measure points/vp/rank/etc. and use that information to sort teams.

I was also told that I have no idea what the Fair Play situation was, which is totally correct.  I do remember when Fair Play had a measure to prevent ppl from switching teams for a certain period at the beginning of matches.  I was told that "the developers" told Fair Play that they could not do anything like this, or their server would be de-listed from the launcher.  Again, I don't know the situation, and I'm no pillar of the community, but I don't understand why balance-related measures can't be experimented with on a per-server basis if the developers say they are unable to do anything about it themselves.

It's one, but there is no overarching mechanism that calculates all different factors to try and balance teams, especially based on roles. There was an "MMR" system that is based on the points of previous matches to try and give a "team score" type thing. There's not really much we can do outside of that. It's quite hard to develop a system that can be based on any sort of skill measure while not having any "right" method of winning, and also not having an account system. The fact of a small community has side effects of imbalanced games. It would be nice if we could have a matchmaking system, or if people would balance themselves. Even with "balanced" players, it's not a surefire way of creating a good match. Some players might not play their best role, they might not even try to win or they might hate the current map and just afk rep until it ends. Creating a system that balances on a tiny sample size will not provide good results, and will most likely make games worse or just the same. I think the best solution would just making more intuitive gameplay, such as the mine radius and more text in-game that can explain mechanics that aren't apparent to new players. A tutorial would also be nice, and has always been on our to-do list.

[crazfulla]

There was always team reshuffle in the original Renegade, but it was fairly random. It made for some interesting matchups, but seldom did they actually yield a perfect balance. It was chaotic at times because you didn't know who your team mates would be at all. That being said I would support a feature being added if it were possible and if it actually benefitted the game.

[Novilan]

I think at this point it would be better to have at least a random shuffle, which shifts like half of the team around, cause at the current state you often end up with the same people. As a somewhat reference point: yesterday I never switched teams and except for one game out of 8 (?) I was on the same team as "slow", who afaik never switches the team.

Although it won't help against people who instantly switch teams due to various reasons.

Edited April 26, 2020 by Denuvian

[Tommy]

I think it would be nice if there would be a scramble/shuffle command for mods/admins or even a vote to do that. You could disable team change for a limited time after the command/vote has been executed.

[Agent]

I feel like there is some miscommunication possibly going on -- to clarify, there is (and has been for a long time), the following shuffle algorithm by default:

private static function ShuffleTeamsNextMatch()
{
	local Array<Rx_Controller> Team1, Team2, All;
	local float Team1Score, Team2Score;
	local int GDICount, NodCount;
	local Rx_Controller PC, Highest;
	local Rx_Mutator Rx_Mut;

	LogInternal("autobal: shuffle" );

	Rx_Mut = `RxGameObject.GetBaseRXMutator();
	if (Rx_Mut != None)
	{
		Rx_Mut.OnBeforeTeamShuffling();
	}		

	if (Rx_Mut != None)
	{
		if(Rx_Mut.ShuffleTeamsNextMatch())
			return;
	}		

	// Gather all Human Players
	foreach `WorldInfoObject.AllControllers(class'Rx_Controller', PC)
	{
		if ( (PC.PlayerReplicationInfo != None) && (PC.PlayerReplicationInfo.Team != None) )
			All.AddItem(PC);
	}

	// Sort them all into 2 teams.
	while (All.Length > 0)
	{
		Highest = None;
		foreach All(PC)
		{
			if (Highest == None)
				Highest = PC;
			else if (Rx_PRI(PC.PlayerReplicationInfo).OldRenScore > Rx_PRI(Highest.PlayerReplicationInfo).OldRenScore)
				Highest = PC;
		}

		All.RemoveItem(Highest);

		if (Team1Score <= Team2Score)
		{
			Team1.AddItem(Highest);
			Team1Score += Rx_PRI(Highest.PlayerReplicationInfo).OldRenScore;
		}
		else
		{
			Team2.AddItem(Highest);
			Team2Score += Rx_PRI(Highest.PlayerReplicationInfo).OldRenScore;
		}

		// If the small team + the rest is less than the larger team, then place all remaining players in the small team.
		if (Team1.Length >= Team2.Length + All.Length)
		{
			// Dump the rest in Team2.
			foreach All(PC)
				Team2.AddItem(PC);
			break;
		}
		else if (Team2.Length >= Team1.Length + All.Length)
		{
			// Dump the rest in Team1.
			foreach All(PC)
				Team1.AddItem(PC);
			break;
		}
	}

	// Figure out which team will be which faction. Just do the one that moves the least.
	foreach Team1(PC)
	{
		if (PC.PlayerReplicationInfo.Team.TeamIndex == 0)
			++GDICount;
		else
			++NodCount;
	}
	if (GDICount >= NodCount)
	{
		// Team 1 go GDI, Team 2 go Nod
		foreach Team1(PC)
			`RxEngineObject.AddGDIPlayer(PC.PlayerReplicationInfo);
		foreach Team2(PC)
			`RxEngineObject.AddNodPlayer(PC.PlayerReplicationInfo);
	}
	else
	{
		// Team 1 go Nod, Team 2 go GDI
		foreach Team1(PC)
			`RxEngineObject.AddNodPlayer(PC.PlayerReplicationInfo);
		foreach Team2(PC)
			`RxEngineObject.AddGDIPlayer(PC.PlayerReplicationInfo);
	}

	if (Rx_Mut != None)
	{
		Rx_Mut.OnAfterTeamShuffling();
	}	

	// Terribly unoptimized, but done.

The above code essentially sorts players into teams based on the OldRenScore from the just completed match, which to the best of my understanding is akin to how Renegade sorted teams. I'm not sure why these mutator hooks exist in this particular place, nor why they only check the first mutator in the mutator list, but I suppose those are there as well to make it possible for mutators to adjust team balancing.

 

A leaderboard based/influenced, or even MMR based/influenced, shuffling option has been planned for some time. I was under the impression something had already been implemented for MMR-based shuffling, however I cannot seem to find an algorithm implementation for it at this time.

[Tytonium]

On 4/25/2020 at 11:59 PM, Sarie said:

It's one, but there is no overarching mechanism that calculates all different factors to try and balance teams, especially based on roles. There was an "MMR" system that is based on the points of previous matches to try and give a "team score" type thing. There's not really much we can do outside of that. It's quite hard to develop a system that can be based on any sort of skill measure while not having any "right" method of winning, and also not having an account system. The fact of a small community has side effects of imbalanced games. It would be nice if we could have a matchmaking system, or if people would balance themselves. Even with "balanced" players, it's not a surefire way of creating a good match. Some players might not play their best role, they might not even try to win or they might hate the current map and just afk rep until it ends. Creating a system that balances on a tiny sample size will not provide good results, and will most likely make games worse or just the same. I think the best solution would just making more intuitive gameplay, such as the mine radius and more text in-game that can explain mechanics that aren't apparent to new players. A tutorial would also be nice, and has always been on our to-do list.

You know as useless as my Lean Six Sigma class has been for the entirety of this college semester, there is one bit of actual useful information that can be gathered from it.

No matter how complex a system's problems seem on the outside, thinking through the system in a logical and introspective way can usually net you a simple and easy fix.

The question presented is why can we not balance matches based on a previous matches score?

A good reason is that player scoring is somewhat arbitrary. I think the biggest blame can be put onto arty/mrls spamming. You can have someone kill over a 100 people on the enemy team per match, but they will be thousands and thousands of points behind the cheeky bastard who hid his artillery in an invulnerable position and spammed a single building for 15 minutes. Raise the amount of points and vp you receive for killing infantry and maybe cap the amount of points and vp you can get from building damage for ever minute or 5 minutes, or even just substantially lower the amount of points/vp you can get from building damage.

Simply put, fix player scoring and perfect balancing can be achieved, as all things should be.

Also the sample size can be fixed if you were to make it so that the average score of a player was calculated based on the previous 3-5 matches they last played. That'd be harder to code but I bet it would help.

[Mystic~]

Just a thought, in the past I proposed the idea of slightly boosted handicap stats for "newbie" players on health and armour, it would use some sort of trust system so veteran players don't abuse it, and then maybe their names appear in a new colour with a (n) for new on their name or something. But it might then be possible to ensure both teams have equal new players by splitting by number and then disable it for that player after 90 days.

[Agent]

5 hours ago, Tytonium said:

Also the sample size can be fixed if you were to make it so that the average score of a player was calculated based on the previous 3-5 matches they last played. That'd be harder to code but I bet it would help.

The key issue with using past-match data is that there is not yet a unique or universal user ID that can be used and trusted -- usernames can be changed, Steam isn't an enforced requirement, we haven't yet implemented any login system, and any hardware-based ID is inherently not a user ID. We do still hope to implement a login system to fix this issue, however work has not actually been started on it beyond the UMLs I drafted to show the general login flow and architecture. The key objectives of that login system are to provide a user ID that is always available, always unique, and always trustworthy/verified. This would have massive (but positive) implications for our infrastructure, necessitating updates to the leaderboard and other systems to use this ID. After that the ID would almost certainly end up being incorporated into some sort of server-local or global long-term balancing system, likely tied into leaderboard statistics and possibly displayed in some way on the leaderboard. Eventually I'd love to be able to hover over a user's forum profile, and see their leaderboard rank or have their leaderboard profile integrated with the forum profile page.

There's a lot of moving parts though. In order to keep user credentials secure for example, no UnrealScript code can be trusted to store or manage that data directly (since a malicious server could theoretically use a mutator to steal someone's login credentials or session). Game clients can't pass any of their login information, or even be capable of passing their login information (beyond the unverified user ID) to the game server, for exactly that reason. Thus all actual login management code essentially has to be tied into our DLLBinds, which would be written in C/C++. This DLLBind would have to manage any web API calls to login or register, would have to interact with the Windows registry to store any cached login token, and would have to be polled for login status by the UnrealScript code, etc. The UnrealScript side would actually be relatively simple, since it'd only have to interact with the Flash-based UI for logins, and communicate those values to the DLLBind. Since the game servers can't necessarily trust data provided by the game clients, and since the server list can't necessarily trust data provided by the game servers, user ID validation requires a top-down approach of sorts: the game client tells the server list it's joining a server, the server list passes this on to the verification endpoint (likely somewhere on this website) and waits for a response, then the server list marks the player as verified and informs the game server (or if a negative response is received, kicks the client for an invalid login). That web API that manages the requests for registration, login, and validation requires PHP familiarity, and would have to interact with this forum software's own REST API to manage those requests effectively.

What I'm trying to say with the above is, it's not a trivial task to implement a trustworthy and reliable user ID. It is doable, and the way to get there has been planned out. We just haven't gotten to it yet though, since it requires all of those moving parts: Flash (login/registration UI), UnrealScript (tie the UI to the DLLBind), C/C++ (Jupiter / server list changes, DLLBind for credential and API call management), Windows registry (authentication caching), PHP (authentication API), etc. It's a multiple-person task, and would likely require the combined efforts of several developers, just because no single person on the team is familiar with all of those components. I for example have never touched Flash and have limited exposure to PHP. Only 1 active dev is familiar with Flash / Scaleform. I'm not sure if anybody on the team is actually comfortable with PHP, though there is someone who might help us out on that front. I'm the only one who's worked on Jupiter (which powers the server list) in any significant capacity, so that (and probably the DLLBind) would end up having to fall on me to implement. This doesn't mean it won't happen though -- the process was already planned out because I'd planned for us to tackle this at some point. Our priorities have been elsewhere though, and I for example have been working more on development resources and infrastructure in the background, than I have actual code.

Sometimes it might sound like I'm exaggerating the complexity of a task, but I'm actually trying to ensure we have every base covered and that we don't have to worry about massive security holes or such. Software developers, myself included especially, are notorious for underestimating the time or effort required for a piece of work, because unless something has been planned out in detail, it's impossible to actually know what's all required. We do have the above mapped out though; we know exactly how much work it is: somewhat substantial, but not too substantial as to rule out.

The original game server architecture for RenX is also inherently server centric, and a lot of that remains today. Originally, we didn't even have the capability to monitor in-game activity and track player performance like we do now via the leaderboard's infrastructure. Originally there we didn't have the capability for global moderators, or any sort of real global moderation. Servers are entirely community provided, and they're expected to be capable of functioning on their own even if the server list is down for example. We're definitely better off than we were before though in terms of infrastructure capability, and having what we have now definitely does improve our ability to implement things like user IDs. We've tried quick-and-dirty solutions like using combinations of existing IDs to calculate player MMRs for example, but those are inherently going to always be limited to that specific server. The next step, a global balancing system, absolutely needs all of the above, and I hope we get to start work on that soon.

 

 

Beyond that, once we have a user ID that we can rely upon, we can start hammering out the details for a better balancing algorithm. Right now, we can't take previous match data for the aforementioned reason (we can't reliably track it), so the best we can do is somewhat track player data on a per-server level, or to use the data for any match just completed (which is what the shuffling algorithm above does). If anybody is willing to incrementally improve the existing approaches, I have no doubt that server owners would be more than happy to test those changes out. I have no doubt that a reasonable code change could be incorporated into the base game.

 

Also, sorry for the wall of text lol, hadn't planned to type nearly that much.

[AshbyJones]

thank you Agent for all the info you've provided--sounds like you may have a better idea of what's going on than the other developers who I'd heard from.  Ultimately I'm happy to hear that the developer(s) are conscious of this issue and are working to fix it....the info I'd gotten was from the perspective that enough developers just enjoyed the roflstomps to the point that nothing would ever happen.

I'm not able to understand the code you provided earlier, but I'm curious whether you're surprised that the current sorting doesn't work as well as one would like?

[Something.Incredible]

3 hours ago, AshbyJones said:

thank you Agent for all the info you've provided--sounds like you may have a better idea of what's going on than the other developers who I'd heard from.  Ultimately I'm happy to hear that the developer(s) are conscious of this issue and are working to fix it....the info I'd gotten was from the perspective that enough developers just enjoyed the roflstomps to the point that nothing would ever happen.

I'm not able to understand the code you provided earlier, but I'm curious whether you're surprised that the current sorting doesn't work as well as one would like?

Im not an Agent, but i'll try to save dev's time and explain a bit.
About algo - imagine 64 players (Pool, AllPlayers, no team). All of them have Score. And imagine 2 empty teams.
Now pick a player with Highest Score and put it to the Team with lower Total (sum) Score. 
After you picked and placed - check Teams sizes. At some point there might be a situation like Team1 has 1 player with 100 Score (example, lets name him Player100) and Team2 have 5 players  with sum score = 60. And the Pool has 4 players left with 0 Score each, like newcomers or sort of. Then all of them will go to team1. And thats basically all the algo.
And the 1 issue i see - Player with rank 100 will play mostly alone against 5 players that at least know what to do, comparing to newcomers in Team1. And next match will be the same, again, and again, until Players Scores are balanced to that situation. I can bet Player100 will hate this game soon, newcomers also will suffer agains more skilled players as they have no chance to play with same "noob" team. Well the "solution" is Ranked servers. But eventually that will not happen, we dont have so much players to populate multiple servers. And "multiple servers" needs to be hosted somewhere and someone needs to take care of them, moderate, etc.
Overal problem is that we have Score VP-based only. We dont have Role classifications, like Inf, Rep, Snipers, Commanders, Sneakers etc. A lot of things could be applied here but that will be a huge (VERY HUGE) amount of work. Also this will hit server performance drasticaly. This things could be done without Auth system, but priorities, we will shuffle between teams ourself anyway and Developers have slightly more important work to deal with right now. 

[kira]

8 hours ago, Agent said:

The key issue with using past-match data is that there is not yet a unique or universal user ID that can be used and trusted -- usernames can be changed, Steam isn't an enforced requirement, we haven't yet implemented any login system, and any hardware-based ID is inherently not a user ID. We do still hope to implement a login system to fix this issue, however work has not actually been started on it beyond the UMLs I drafted to show the general login flow and architecture. The key objectives of that login system are to provide a user ID that is always available, always unique, and always trustworthy/verified. This would have massive (but positive) implications for our infrastructure, necessitating updates to the leaderboard and other systems to use this ID. After that the ID would almost certainly end up being incorporated into some sort of server-local or global long-term balancing system, likely tied into leaderboard statistics and possibly displayed in some way on the leaderboard. Eventually I'd love to be able to hover over a user's forum profile, and see their leaderboard rank or have their leaderboard profile integrated with the forum profile page.

There's a lot of moving parts though. In order to keep user credentials secure for example, no UnrealScript code can be trusted to store or manage that data directly (since a malicious server could theoretically use a mutator to steal someone's login credentials or session). Game clients can't pass any of their login information, or even be capable of passing their login information (beyond the unverified user ID) to the game server, for exactly that reason. Thus all actual login management code essentially has to be tied into our DLLBinds, which would be written in C/C++. This DLLBind would have to manage any web API calls to login or register, would have to interact with the Windows registry to store any cached login token, and would have to be polled for login status by the UnrealScript code, etc. The UnrealScript side would actually be relatively simple, since it'd only have to interact with the Flash-based UI for logins, and communicate those values to the DLLBind. Since the game servers can't necessarily trust data provided by the game clients, and since the server list can't necessarily trust data provided by the game servers, user ID validation requires a top-down approach of sorts: the game client tells the server list it's joining a server, the server list passes this on to the verification endpoint (likely somewhere on this website) and waits for a response, then the server list marks the player as verified and informs the game server (or if a negative response is received, kicks the client for an invalid login). That web API that manages the requests for registration, login, and validation requires PHP familiarity, and would have to interact with this forum software's own REST API to manage those requests effectively.

What I'm trying to say with the above is, it's not a trivial task to implement a trustworthy and reliable user ID. It is doable, and the way to get there has been planned out. We just haven't gotten to it yet though, since it requires all of those moving parts: Flash (login/registration UI), UnrealScript (tie the UI to the DLLBind), C/C++ (Jupiter / server list changes, DLLBind for credential and API call management), Windows registry (authentication caching), PHP (authentication API), etc. It's a multiple-person task, and would likely require the combined efforts of several developers, just because no single person on the team is familiar with all of those components. I for example have never touched Flash and have limited exposure to PHP. Only 1 active dev is familiar with Flash / Scaleform. I'm not sure if anybody on the team is actually comfortable with PHP, though there is someone who might help us out on that front. I'm the only one who's worked on Jupiter (which powers the server list) in any significant capacity, so that (and probably the DLLBind) would end up having to fall on me to implement. This doesn't mean it won't happen though -- the process was already planned out because I'd planned for us to tackle this at some point. Our priorities have been elsewhere though, and I for example have been working more on development resources and infrastructure in the background, than I have actual code.

Sometimes it might sound like I'm exaggerating the complexity of a task, but I'm actually trying to ensure we have every base covered and that we don't have to worry about massive security holes or such. Software developers, myself included especially, are notorious for underestimating the time or effort required for a piece of work, because unless something has been planned out in detail, it's impossible to actually know what's all required. We do have the above mapped out though; we know exactly how much work it is: somewhat substantial, but not too substantial as to rule out.

The original game server architecture for RenX is also inherently server centric, and a lot of that remains today. Originally, we didn't even have the capability to monitor in-game activity and track player performance like we do now via the leaderboard's infrastructure. Originally there we didn't have the capability for global moderators, or any sort of real global moderation. Servers are entirely community provided, and they're expected to be capable of functioning on their own even if the server list is down for example. We're definitely better off than we were before though in terms of infrastructure capability, and having what we have now definitely does improve our ability to implement things like user IDs. We've tried quick-and-dirty solutions like using combinations of existing IDs to calculate player MMRs for example, but those are inherently going to always be limited to that specific server. The next step, a global balancing system, absolutely needs all of the above, and I hope we get to start work on that soon.

 

 

Beyond that, once we have a user ID that we can rely upon, we can start hammering out the details for a better balancing algorithm. Right now, we can't take previous match data for the aforementioned reason (we can't reliably track it), so the best we can do is somewhat track player data on a per-server level, or to use the data for any match just completed (which is what the shuffling algorithm above does). If anybody is willing to incrementally improve the existing approaches, I have no doubt that server owners would be more than happy to test those changes out. I have no doubt that a reasonable code change could be incorporated into the base game.

 

Also, sorry for the wall of text lol, hadn't planned to type nearly that much.

hey @Agent

why not using temp tokens that are created and destroyed?                                                                                                                              That way you can have unique Id for every user,   and when he logs in there is a temporary token to use for the auth stuff and storing the stats of the scoring and how the player got the scoring (how many kills\points\deaths  from MRLS, mammoth, med, arty,   each and every vehicle and weapons shall be noted and stored) 

now with the stats information you can know oh this player usually kills 40 players in a match using MRLS on average,
but this other player kills 40 players mostly as mobius. 
then you can relay on that info to build the algorithm.

*****

as i said before on the discord, i am on "vacation"  and have PLENTY OF TIME,  i am backend developer
I'm good with C#, C++,PHP , Unrealscript, and doing restfull api and such.

the suggestions you wrote sounds challenging but if you can send document with instructions ill see what i can do.

 

 

Edited April 28, 2020 by kira
KANE WISHES ME TO EDIT

[yosh56]

3 hours ago, Something.Incredible said:

.
Overal problem is that we have Score VP-based only. We dont have Role classifications, like Inf, Rep, Snipers, Commanders, Sneakers etc. A lot of things could be applied here but that will be a huge (VERY HUGE) amount of work. Also this will hit server performance drasticaly. 

Just here to clarify: the total score isnt 100% VP based. Most things you get VP for you get score for, but it's weighted differently so everyone has an 'equal' shot at scoreboard position. 

VP literally takes into account infantry reps and snipers... maybe not infiltrators so much, sans when they're killed.

And finally.... basic math is actually not adding huge server overhead. It already does that to calculate score, and it's a negligible performance hit, as it really is just a series of short-ish equations. People completely overlook just how many events and stats there actually are that go into VP.

[Something.Incredible]

5 minutes ago, yosh56 said:

Just here to clarify: the total score isnt 100% VP based. Most things you get VP for you get score for, but it's weighted differently so everyone has an 'equal' shot at scoreboard position. 

VP literally takes into account infantry reps and snipers... maybe not infiltrators so much, sans when they're killed.

And finally.... basic math is actually not adding huge server overhead. It already does that to calculate score, and it's a negligible performance hit, as it really is just a series of short-ish equations. People completely overlook just how many events and stats there actually are that go into VP.

Thank you for an answer! About server overhead - i meant only Classification and "a lot of things" (in case it can be able to separate roles in a really wide scope). Like VP to Doza for killing 3 random soldiers in tunnels vs 3 random soldiers near MCT while all the team is on the field in tanks/reps. There could be a lot of different scenarios. And i said about performance mostly because of some random lags in 64-playered matches, any additional check or calculation or thread sync... One more, and one more, plus codebase expands slowly, plus ping, plus ddos.. Well actually i have no idea about how servers are working all that, where are the bottlenecks (well ddos is ddos), how really Score is calculated, i can only guess, so i will stop act "smart" asap  Thanks!

[Guest Once Upon the time]

There are many games where matchmaking is claimed and there are professional devs who are responsible for a part in a game.
Full-time for remuneration. Ren x Devs don't get cash.
An example WOWS:
There, complaints about the MM have been going on for years and will probably always be so, because a skill-based matchmake is subject to far too many influences.
The people are registered there, but there are already differences in the state of the ship (expansion stages) and also captain expansion.
and so on.
People often complain about landslide victories or defeats.
Ren X doesn't have as many players as WOWS.
Maybe it would be helpful if mods are online, that they make the teams fairer. You know each other.
Assumes that a mod wants a more balanced game, or play with friends.
I can't and don't want to judge that anymore.

[RypeL]

Also just here to clarify: The current balancer doesent just balance based on score. It takes a combination of score and amount of kills into account. I think I already posted the formula in the forums sometime somewhere. The posted code is only half the picture that’s why it doesent Show any kills beeing taken into account. 
And yeah, RX devs don’t get paid so you can’t do it for life and disagreements in the dev team can get to you too. Part of the reasons I left and since i was handling most of that balancer there aren’t much people left who could work on it so ya. 
@kiraI added enough mutator hooks to the balancer so that it’s possible to change or completely replace it with a mutator. So if you really would wanna take the time to get into it you could get full control over it with a mutator and could try it out that way without having to wait for game updates etc.

[kira]

29 minutes ago, RypeL said:

Also just here to clarify: The current balancer doesent just balance based on score. It takes a combination of score and amount of kills into account. I think I already posted the formula in the forums sometime somewhere. The posted code is only half the picture that’s why it doesent Show any kills beeing taken into account. 
And yeah, RX devs don’t get paid so you can’t do it for life and disagreements in the dev team can get to you too. Part of the reasons I left and since i was handling most of that balancer there aren’t much people left who could work on it so ya. 
@kiraI added enough mutator hooks to the balancer so that it’s possible to change or completely replace it with a mutator. So if you really would wanna take the time to get into it you could get full control over it with a mutator and could try it out that way without having to wait for game updates etc.

Thank you for replying, but still there is a need for statistics to know better the user abilities which different tanks, weapons and such, over few game matches and saving it uniquely to the user to make it automated. 

 

 

[Guest Once Upon the time]

Hi Kira

1. Players can change their names as they like.
2. If I remember correctly, not all data is recorded "centrally" (if not correct, then please excuse me).
3.Steam is not mandatory and there are still players who don't use Steam.
4.Data from each player how he plays what? A hell of a lot of data. Even when calculating few games.
 

Conclusion:

Same problem as with WOWS and they saved the data somewhere. They haven't been able to do that for years and as written, these devs do the main job.
Ren X Devs as a hobby.
WOWS also only has a "Basic MM".
Have fun collecting data.

[Agent]

1 hour ago, RypeL said:

Also just here to clarify: The current balancer doesent just balance based on score. It takes a combination of score and amount of kills into account. I think I already posted the formula in the forums sometime somewhere. The posted code is only half the picture that’s why it doesent Show any kills beeing taken into account. 

Yup, `OldRenScore` is a slight misnomer now since the balancing code has sort of spread out and isn't just your previous match's score (which to be honest, I'd actually assumed it still was). To further clarify, it looks like your initial OldRenScore IS populated based on your previous server-local performance (using the aforementioned MMR stuff) as so:

NewPRI.OldRenScore = PlayerMonitor.MyPlayersInfo[PlayerListIndex].SavedScore / PlayerMonitor.MyPlayersInfo[PlayerListIndex].JoinedGame;	

And the server-local score information is maintained via Rx_PlayerMonitor:

class Rx_PlayerMonitor extends Actor
	config(PlayerMonitor);

struct PlayersInfo
{
	var string PlayerName;
	var string UUID;
	var float SavedScore;
	var float LastGameScore;
	var int JoinedGame;
};

var config Array<PlayersInfo> MyPlayersInfo;

function AddNewinfo(string ID,float Score,string MyName)
{
	local PlayersInfo NewInfo;

	NewInfo.UUID = ID;
	NewInfo.SavedScore = Score;
	NewInfo.LastGameScore = Score;
	NewInfo.JoinedGame = 1;
	NewInfo.PlayerName = MyName;

	MyPlayersInfo.AddItem(NewInfo);
	SaveConfig();
}

function float UpdateInfo(Rx_Controller Player)
{
	local string PlayerID;
	local float Score;
	local int Index;

	PlayerID = Player.PlayerUUID;
	Score = CalcPlayerScore(Rx_PRI(Player.PlayerReplicationInfo));
	Index = MyPlayersInfo.Find('UUID',PlayerID);
	if(Index >= 0)
	{
		MyPlayersInfo[Index].LastGameScore = Score;
		MyPlayersInfo[Index].SavedScore += Score;
		SaveConfig();
	}
	else
		AddNewInfo(PlayerID,Score,Player.PlayerReplicationInfo.PlayerName); // shouldn't really happen, but just in case

	return Score;

}

function float CalcPlayerScore(Rx_Pri pri)
{
	local float ret;

	ret = pri.GetRenScore();
	if(ret < 1.0)
		ret = 0.0;
	else	
		ret = loge(pri.GetRenScore());

	if(pri.GetRenKills() - pri.Deaths > 0)
		ret += loge((pri.GetRenKills() - pri.Deaths) / 2.0);

	return ret;
}

The kill inclusion RypeL mentioned is seen above in CalcPlayerScore(), for anybody who wants to get a closer look into how things are presently setup.

[AshbyJones]

All I know is the current shuffle doesn't work right.  The latest patch has some cool features, but PLEASE prioritize shuffling over these new features..........