Jump to content


Popular Content

Showing content with the highest reputation on 03/15/2018 in all areas

  1. 3 points

    Improving the handicap mutator

    I believe the general consensus is that the handicap mutator makes little difference, and I think this should be addressed. Critically, I think the mutator should let the losing player have /fun/. Time for some brainstorming! I think a good potential direction is for the mutator to apply a multiplier to damage output and/or damage resistance (regardless of armours). I also think rather than having it scale as the score differential increases isn't necessarily the best thing. I was thinking perhaps a scaleable mutator that you can vote for. e.g. vote for a 2x multiplier to damage output, or a 1.2x multiplier. That way as the player learns new things and progresses, they can request a smaller multiplier than they previously used and get a sense of achievement/improvement. Some testing would probably be required to see just how much extra damage output a good player could handle, but I think this would go a long way towards letting a complete noob take a fight and have some fun. Perhaps it doesn't even matter if it means the player with the mutator is going to win. Good players won't care and it'd be fun to figure out ways to handle the situation (although being careful not to turn it into a bolt fest). The game really needs to handle this better to increase new player retention. A new player is most likely to get a duel as their first game (they might queue for ffa and not get a game but you only need /one/ player to get a duel, right?). It's crushing for a new player to get stomped and we all know even a small skill difference can lead to 50:0 games. Let's soften the inevitable early blows and let new players have FUN fighting, trying out the weapons, and jumping around the map. Let them know they're being afforded an advantage that they can opt to scale down if they want to improve. Lastly, @shooter, how does the handicap mutator currently work? I believe it increases stack progressively in line with point difference?
  2. 3 points

    Improving the handicap mutator

    I think it's bad idea to scale damage either way if the point of the mutator is to make the games less frustrating for weaker players. This makes fighting inconsistent between non-handicap and handicap games. You'll develop habits where you think you can take fights with lower stacks simply because the enemy deals less damage. Basically "Oh I can probably survive 2 directs" should never be a thought process if you have <=200 stack. You should instead buff/nerf players by changing the amount of health/armor/weapons they spawn with since this will result in scenarios that also apply in "real" games. So let's say we want the better player to do 0.5x damage then it's better to just double the amount of stack the weaker player has.
  3. 2 points

    Improving the handicap mutator

    One of the reason the current system doesn't work is because (correct me if I'm wrong) the players that has the lowest score gets a spawn armor and health boost, even if it is the better player. This is not good, the handicap must target one particular player, whatever the score is.
  4. 1 point

    Thunder FFA #1

    Yo welcome to FFA event. If you like FFA feel free to join and play. We play every week. Date: Thursday, March 15, 2018 Session Start: Central Europe: 20:00, United Kingdom: 19:00, Russia / Moscow: 22:00 Mode: FFA only Server: Capodecima's FFA server
  5. 1 point

    Improving the handicap mutator

    That is absolutely fair, and I was aware of it - my reasoning was the weaker player would be aware of what was going on, so should also be aware of the risk of forming bad habits. If they decide to get serious about it, they'd obviously strive to not need any kind of handicap system. I'm also thinking about the game of go, where the weaker player can start with some of their stones already on the board. As they get better, they reduce that number of stones. Fun fact, that is where martial art grades/belts come from (white belt would be 9th kyu, 9 stones, etc etc). And of course, it would give them a fun game, hopefully. A very good point! Also a very good point! There's never a simple solution eh. This is why i'm thinking different types of handicap mutator would be a nice option. That way you're aware of what you're getting (free extra damage to the scale of x, or free global damage resistance to the tune of y).
  6. 1 point

    Improving the handicap mutator

    Don't ONLY reduce the damage that the handicapped player has - imagine a situation where the better player is handicapped. Neither player would do damage in a fight because the noob can't aim/would get dodged and the handicapped player's damage is reduced. The better player can then choose when to run and use his superior movement to fall back on hp/armors. Game never ends etc. I support making the handicapped player take more damage as well.
  7. 1 point


    I wish "gconst_playeronground_speed" didn't intervene with air movement. So in other words, kill the bind between ground and air variables first. Then add the following cvars: gconst_playerinair_wishspeed (to be 320 by default) gconst_playerinaircrouched_wishspeed (to be 120 by default) And other possibly handy cvars: gconst_double_jump_expiration (the time window during which the double jump has to be executed) gconst_wallclipping_expiration (the time window during which you have to have cleared away from the obsacle) gconst_stepheight (to be 18 by default) gconst_stepup (the stepup behavior used in stair jumps - 0 disabled / 1 enabled) gconst_crouchhop (enable jumping while holding crouch - 0 disabled / 1 enabled) gconst_autohop (enable jumping without releasing jump key - 0 disabled / 1 enabled) It would also be really nice, if air control and bunnyhop were not locked to W/S and A/D keys exclusively. There would be more freedom if the cvars were arranged as follows: gconst_aircontrol_straight (the only supported aircontrol direction atm) gconst_aircontrol_sideways gconst_aircontrol_strafe And the same logic for bunnyhop (note that 2 cvars each are required): gconst_bunnyhop_straight_accelerate gconst_bunnyhop_straight_wishspeed gconst_bunnyhop_sideways_accelerate (the only supported bunnyhop direction atm) gconst_bunnyhop_sideways_wishspeed (the only supported bunnyhop direction atm) gconst_bunnyhop_strafe_accelerate gconst_bunnyhop_strafe_wishspeed Also, a simple cvar to disable bunnyhop variables, so you don't have to play with all of these variables in order to replicate vQ3 or QW movement for example: gconst_bunnyhop (0 disabled / 1 enabled)