Gameplay Roadmap - 2.1.2 Varying confidence thresholds

Request new features or present your ideas.
Post Reply
User avatar
Viech
Project Head
Posts: 2139
Joined: Fri Aug 03, 2012 11:50 pm UTC
Location: Berlin

Gameplay Roadmap - 2.1.2 Varying confidence thresholds

Post by Viech »

2.1.2 Varying confidence thresholds wrote:

In the original confidence design, rewards, half life time and stage thresholds were all fixed and thus independent of time. As a result it was possible to stage down in late game which resulted in weak guns being used against a lot of (higher stage) defense buildables. The match would end in a tie eventually. This was fixed by giving stage thresholds a half life time, too. This works but having two independent nonlinear functions seems like unncessary complexity to me.

Ishq wrote:

I think the main reason complex feels to opaque and complex is because we are too focused on providing exact numbers. For instance, in reality, the amount of confidence you have and your confidence threshold are both meaningless individually. They only mean something when put together, so why even display them separately? Display confidence as a percentage to the next stage or a progressbar, thus hiding the fact that confidence is actually dictated by two varying nonlinear functions. It doesn't matter how hard or complex our underlying systems are as long as we can wrap a pretty interface over it. The player doesn't need to know that you will get exactly 25.3455 confidence for building a buildable in a certain location, he really only needs to know he will get more building there as opposed to building somewhere else. The simple fact that confidence awards are directly proportional to the risk is intuitive enough to understand. I am for adding more complexity and more special cases to the confidence system to make a finely tuned beast, but hide that behind generalities. For instance, beyond perhaps dretch, granger, and the naked human, no one has reward values for each class memorized. They don't need to know either, they just need to know that they will get more credits for killing a tyrant than a dragoon, and more for a dragoon than a marauder.

Responsible for: Arch Linux package & torrent distribution, Parpax (map), Chameleon (map texture editor), Sloth (material file generator), gameplay design & programming, artistic direction

User avatar
kharnov
Granger
Posts: 1851
Joined: Tue Mar 06, 2012 10:54 pm UTC
Clan: GT
Location: New York City

Re: Gameplay Roadmap - 2.1.2 Varying confidence thresholds

Post by kharnov »

I agree with the assessment of counter-productive precision. There are far too many numbers to keep track of already, like how much health you have remaining, your ammo, your credits, etc. Something like a progress bar would be much more visually appealing than a line of rapidly changing numbers at the bottom of your screen, and would provide a more comprehensible way of knowing when you're going to stage up.

On another note, shouldn't we make it very hard to lose stage 3 after you've achieved it? I mean, I don't think it would be very fair if you've done so well that you've gotten a tyrant or a battlesuit, only to lose your momentum just because someone chucks a grenade into your base or zaps a few buildings. Sure, you might end up with both teams staying for a long time at stage 3, but it's much more interesting to play than repeating the early game with both teams at stage 1 all over again.

User avatar
Viech
Project Head
Posts: 2139
Joined: Fri Aug 03, 2012 11:50 pm UTC
Location: Berlin

Re: Gameplay Roadmap - 2.1.2 Varying confidence thresholds

Post by Viech »

Don't presuppose the existance of rigid stages. Apart from that I see your point. The current implementation already includes a countermeasure (as explained in the relevant section) and my solution 2.1.2.1 also accounts for it. In late game, it should be easier to maintain access to stronger equipment.

Responsible for: Arch Linux package & torrent distribution, Parpax (map), Chameleon (map texture editor), Sloth (material file generator), gameplay design & programming, artistic direction

Post Reply