Let’s Start Rewarding Players for Playing the Objective

[Ozzy 2,003]

Description: Players will get rewards in the form of XP and Money (maybe) when playing within the cap zone of objectives. This will incentivize more gameplay around objectives and less gameplay around each base.

 

Reasoning: Honestly seems like a huge win-win. With an update like this, basecamping will decrease and player happiness will increase. There is currently no incentive short of altruism to stay on the objective once it’s capped. Players will push up as far as they can within the confines of the rules. Base camping is a valid strategy and I don’t condemn those that do it within reason. However, I feel that adding XP and Monetary rewards to playing around the objective, will incentivize more players to stick close.

”I really don’t care about experience and money is currently worthless.” At this point in time there is no counter-argument to that. Prestige offers incentives sure, but that goal is a long-term play in this world where we chase instant gratification. I know Garnet is open to creating more rewards for Prestiging  and I’m going to be making a post regarding the economy on the server, ideally making in-game money worth something.

The Numbers:

- Experience and Money per tick (Ticks are every 10 seconds; meaning 180 possible* ticks per war) = 20 exp and $10

- Experience and Money per capture = 500 exp and $250

-Experience and Money per attacking kill (other country has OBJ capped) = 200 exp and $100

- Experience and Money per neutral kill (no country has OBJ capped) = 175 exp and $75

- Experience and Money per defending kill (your country has OBJ capped) = 150 exp and $50

 

Additional Information: N/A

[AlexConway 1,166]

1 hour ago, 0zzy said:

Experience and Money per tick (Ticks are every 10 seconds; meaning 180 possible* ticks per war) = 20 exp and $10

Tickrate is definitely not 10 seconds - might be how frequently the system updates the war system, but it's not 10 seconds. I did talk to garnet about this exact thing before (XP for Capping an OBJ), and the amount of lag from the server for doing these calculations per 10 seconds, hitreg would be significantly worse. Not only does the server have to registered the 50 bullets per second, or what not; now it has to track players and give them XP and Money.

There is a reason the OBJ system isn't a live update.

1 hour ago, 0zzy said:

-Experience and Money per attacking kill (other country has OBJ capped) = 200 exp and $100

- Experience and Money per neutral kill (no country has OBJ capped) = 175 exp and $75

- Experience and Money per defending kill (your country has OBJ capped) = 150 exp and $50

Again, you're going to sacrifice hitreg accuracy, every time a hit is registered, the code has to check more and more variables, causing more and more delay - and less accurate hitreg.

 

1 hour ago, 0zzy said:

will incentivize more players to stick close.

Not to be toxic but, how bout the incentive is the officers, tell people to play the gamemode otherwise you get removed for not listening...

 

I do agree this would be cool, by all means, I know MRP players love hitreg, and get mad when it's not reliable, so just food for thought. -1 sorry

Edited July 9, 2020 by AlexConway

[Ozzy 2,003]

1 minute ago, Alex Conway said:

Tickrate

Not what I’m talking about. The capture percentage on objectives updates every 10 seconds.  ie: “We are up 5s per tick.” 
 

3 minutes ago, Alex Conway said:

Hitreg would be 20x worse.

Giving me actual values instead of exaggerations would allow myself and the community to weigh pros and cons easier. 

[AlexConway 1,166]

19 minutes ago, 0zzy said:

Giving me actual values instead of exaggerations would allow myself and the community to weigh pros and cons easier. 

Generously with a perfectly optimized bit of code, 10-15% decrease in reliability, you're adding easily 10+ variables and 10+ Server Events, it's going to lag as the server needs calculate that every-time someone shoots a gun. Realistically, anywhere up to 20-25%, either way, you'd notice it. 

Edited July 9, 2020 by AlexConway

[Lex_ 506]

52 minutes ago, Alex Conway said:

Generously with a perfectly optimized bit of code, 10-15% decrease in reliability, you're adding easily 10+ variables and 10+ Server Events, it's going to lag as the server needs calculate that every-time someone shoots a gun. Realistically, anywhere up to 20-25%, either way, you'd notice it. 

Please don't spread false information again about how the Source engine (and Garry's Mod, specifically) handles PVP (weapons, damage, death). You did this last time when you tried to get rid of friendly fire and its entirely inaccurate.

The laggy part about implementing something like this is calculating the player's position to verify they are on the point. This check would need to be done everytime somebody dies. Not when people take damage, and not when people shoot their guns.

 

The way I've read what Ozzy has posted is like this:

If any objective is capped for the opposing team, you get rewards based on the attacking portion of his post.

If any objective isn't capped, you get rewards based on the neutral portion of his post.

If any objective is capped for your team, you get rewards based on the defending portion of his post.

 

This is the easiest thing to implement that won't kill your performance. The thing that's difficult with implementing it this way (rather than the way Garnet has originally decided) is creating it in a balanced and accurate way. We have 3 total objectives and if the rewards per kill require one objective, it could be random if one objective is capped by the opposition, one objective isn't capped, and one objective is capped by your team.

 

Now, doing the reward per cap-tick and reward for being on point for capturing is also easy. You're already verifying the player is on the objective to modify the percentage change per tick. Giving money or experience will not add any performance strain, that is if its implemented correctly.

[AlexConway 1,166]

21 minutes ago, Torch said:

Please don't spread false information again about how the Source engine (and Garry's Mod, specifically) handles PVP (weapons, damage, death). You did this last time when you tried to get rid of friendly fire and its entirely inaccurate.

The laggy part about implementing something like this is calculating the player's position to verify they are on the point. This check would need to be done everytime somebody dies. Not when people take damage, and not when people shoot their guns.

 

The way I've read what Ozzy has posted is like this:

If any objective is capped for the opposing team, you get rewards based on the attacking portion of his post.

If any objective isn't capped, you get rewards based on the neutral portion of his post.

If any objective is capped for your team, you get rewards based on the defending portion of his post.

 

This is the easiest thing to implement that won't kill your performance. The thing that's difficult with implementing it this way (rather than the way Garnet has originally decided) is creating it in a balanced and accurate way. We have 3 total objectives and if the rewards per kill require one objective, it could be random if one objective is capped by the opposition, one objective isn't capped, and one objective is capped by your team.

 

Now, doing the reward per cap-tick and reward for being on point for capturing is also easy. You're already verifying the player is on the objective to modify the percentage change per tick. Giving money or experience will not add any performance strain, that is if its implemented correctly.

I'm sure Garnet would be open to paying you to help him complete this task in an efficient way; he has made mentions of the "onplayersdeath" hook. I know he might be reluctant to this as you've given him broken code many times in the past, but it's always worth a try.

Edited July 9, 2020 by AlexConway

[Lex_ 506]

Just now, Alex Conway said:

I know he might be reluctant to this as you've given him broken code many times in the past, but it's always worth a try.

Not to put Garnet on blast here, but this isn't what happened - plus "many times" is actually just once.

If you'd like me to explain what I think caused my changes to CW 2 to bug out (hint, it wasn't me), let me know.

[Dexx 395]

+1 Cause 

 

[Ozzy 2,003]

Your suggestion has been Accepted,

Please note that accepted suggestions will not necessarily be implemented into the server, but rather forked over to the development team for a second opinion, at which point they are free to choose between implementation or not. 
 

@proggy or @Enigma please lock.