For what it's worth, I spent 25 years in the games industry working with
the biggest companies in it and I can tell you flat out that many of the
games we helped develop (we were these company's QA source) cheated as a
way of dealing with skill levels high and low. Gnubg in my day would have
never been put out as a boxed product for sale (yes I know that isn't how
it's designed). It would have simply been too insulting to the general
customer as presented.
The way it likely would have been handled would have been to create an
interface that highlights the lowest AI levels calling them things all the
way up to say, "Expert" even though it would maybe be capped at what we
know as Intermediate. The higher levels would then have all been called one
thing ("Professional" perhaps) with a slider to set "how professional".
That would give the average customer the sense that they are only, on
average one or two "steps" away from being amazing. Perception is essential
even if it's not accurate. This would also cut down on the cries of
cheating as most people would never bother to go beyond "Expert".
I'm a big fan of the product so this is all just for perspective purpose. I
would say that maybe it might be an approach for some new UI "skin"
approach someday, if ever.
Why? Nearly everyone I put onto the product gives up on it as they're used
to turning skills up and are also put off by all the daunting terms they
encounter. It works for all the serious people but there are never enough
of those to make a product as popular as it could be, usually by a wide
margin. Worse, a sort of bubble sets in as new ideas only come from that
community. Most of the time people are not able to see beyond their own
needs so the product just becomes more and more painted into an ever
shrinking corner space.
On Thu, Aug 24, 2017 at 1:13 PM, Rich Heimlich <[email protected]> wrote:
> This is scientifically proven to be a losing proposition. Every study on
> this issue shows that humans remember negative stimuli far more than
> positive stimuli.
>
> That said, that does not mean an effort shouldn't be made to attempt to
> offset this. For example, one way that I believe might help some people on
> this would be of the product supported some sort of hypothetical online
> dice rolling app that was coded to work for all sorts of apps like D&D,
> craps, monopoly, etc.
>
> It would be rather more difficult to suggest that such a product neutral
> app could possibly be cheating. It could show a log of the rolls so that
> people couldn't argue that gnubg just claims to connect to it bit either
> does not or simply changes the rolls after the fact.
>
> Telling someone to roll their own dice doesn't work because it's too time
> consuming whereas connecting to a dice app takes only minutely more time
> than normal.
>
> On Wed, Aug 23, 2017 at 8:28 PM, tchow <[email protected]> wrote:
>
>> On 2017-08-21 16:40, Philippe Michel wrote:
>>
>>> The involved math is too hard for me, but wouldn't using low
>>> discrepancy sequences
>>> (https://en.wikipedia.org/wiki/Low-discrepancy_sequence) instead of a
>>> random order decrease the variance for rollouts with any number of
>>> trials (possibly only slightly, with variance reduction already
>>> helping a lot).
>>>
>>
>> In principle, yes, but as I understand it, eXtreme Gammon doesn't use
>> quasi-random dice and its variance doesn't seem to suffer much. If this is
>> true then I would infer that low-discrepancy sequences won't reduce the
>> variance much.
>>
>> Something that might have a better chance of yielding superior results is
>> to use 1-ply or even 2-ply for the variance reduction computation instead
>> of 0-ply, at least for the first or second steps of a rollout trial.
>> Obviously this would slow things down but it's conceivable to me that the
>> improved accuracy of the luck estimate might compensate for it, so that
>> fewer rollout trials would be needed to drive down the variance.
>>
>> Tim
>>
>> _______________________________________________
>> Bug-gnubg mailing list
>> [email protected]
>> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>>
>
>
_______________________________________________
Bug-gnubg mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-gnubg
