Re: PBM design and formulae - a summary

From: gym@dcs.ed.ac.uk (Graham Matthews)

Date: Thu, 01 Jul 1993 11:15:09 +0000

Graham Matthews <gym@dcs.ed.ac.uk> writes:
> I never said that knowledge of the formulas didn't give you a
> serious advantage. Obviously it does. I just said that I think it
> screws the game up. If people know the formulas they tend to :-
> a) write scripts/programs etc to find optimal settings for the
> formulas.
> b) spend hours maximising formulas, adjusting tiny details etc.
> Now my complaint with a) is that it turns the game into a game of
> who can write the best programs, who knows awk, mathematica etc.
> Thats particularly fair on players who are not computer gurus
> isn't it! In short the problem that a) causes is that it allows
> people to bring in far too many skills from *outside* of the
> game-world *into* the game-world if you see what I mean.

desj@ccr-p.ida.org (David desJardins) writes:
>I don't understand why so many people seem to be ignoring what I
>think is the fundamental issue here.  If people don't know the
>formulas, they do _exactly_ the same things that you have described
>above.  They read and analyse their turns, they discover the formulas
>and algorithms that the program is using, they then analyse the hell
>out of the formulas, and find super strategies.
>[example from Legend]

You are not going to be able to back engineer *exact* formulas from
output if either the formulas have some randomness in them, or
if the result of evaluating some formula effects the value of
one of the parameters to that formula (eg: think about combat - the
result of a combat depends on the experience of the combattants,
but the experience of the combattants will change as a result of
the combat).

Moreover you have missed the most important thing, namely that you
might be able to guess an approximate formula, but not the exact
one. Why is this important. It means that the people without the
maths degrees or the CS programming skills are going to be able
to compete on the same terms as those with those skills.
Care to answer this point? You just ignored it last time!

As I said last time, as a game designer I don't like people bringing
too many skills to bear from outside the game world. It rather
defeats the purpose of having skills in the game world. Care to
answer this point? You just ignored it last time!

Graham Matthews <gym@dcs.ed.ac.uk> writes:
>>Firstly it is very easy to not exploit the bugs. Just remember that
>>if you win by exploiting the bugs then its something of a Pyric (sp?)
>>victory. That should stop you exploiting the bugs. Secondly you
>>are not gaining an advantage over "other players who are not so
>>analytical". You are gaining an advantage over the people who are
>>not prepared to stoop to bug exploiting to win.
desj@ccr-p.ida.org (David desJardins) writes:
>I think this is rather fatuous and condescending as long as you are
>not willing to explain to me how to identify a "bug."  I already gave
>an example of what I am talking about: determining that certain types
>of units are not very useful in certain situations, so not building
>them. Are you seriously proposing that I should be ethically required
>to build units that I know won't be very effective, because not doing
>so is "stooping to bug exploiting to win"?
>[example of tanks in WWI]

You are missing the point entirely. Building a tank with -ve armour
because you know that the game does not handle integer wrap correctly
is an example of bug exploitation and yes you should be ethically
required to report it. The WWI tank example you gave is quite a
different thing but illustrate my point about bringing skills into
the game that you should not be able too. You should find out that
tanks are not best used with infantry by trying to use them this way
in the game and if it doesn't work try some other strategy. You
seem to suggest that you find this out by reading the source code
or something. Makes for a pretty noddy game. Now a game is supposed
to simulate something. How realistic do you think the game is that
has players work out their strategy by consulting the game code?
The basic point is that you as a player should only be able to do
things that the party you represent in the game could do in the
game, and the party you represent in the game cannot consult the
source code to see how tanks are best deployed.

Again I ask for an answer to my position that players should only
be able to do things that the party they represent in the game
could do. I hinted at this last time and yet got no comment. Care
to reply directly now?

desj@ccr-p.ida.org (David desJardins) writes:
>Once you find out what works best, that's
>what you are going to do.  How can you do otherwise?  I can't tell if
>you are seriously saying that you should do something that you know
>doesn't work as well, just to compensate for the fact that other
>people might not have figured out that it's not a good idea.

Never said this - you must have been reading some other article. All
I commented on was :-

a) how you got the information about how best to play in the first
place.
b) what type of information was ethical to exploit.

Now back to your tank example. Getting the information that tanks
work best en masse by experimenting with different tactics in the
game is fine. Getting that information by reading source code or
formulas is crazy for the reasons I gave beforehand. Likewise
exploiting that info once you have it is fine, but exploiting
something like negative armour (even when you know others are
doing it) is pointless. Its all a matter of balance.

graham
--
Graham Matthews                   Go west, go west
Dept Comp Sci, Univ Edinburgh     Where there's work so I'm told
gym@dcs.ed.ac.uk                  California's never cold

References

Re: PBM design and formulae - a summary
desj@ccr-p.ida.org (David desJardins)
Tue, 29 Jun 1993 21:24:09 +0000
Re: PBM design and formulae - a summary
gym@dcs.ed.ac.uk (Graham Matthews)
Wed, 30 Jun 1993 10:33:28 +0000
Re: PBM design and formulae - a summary
desj@ccr-p.ida.org (David desJardins)
Wed, 30 Jun 1993 20:13:49 +0000
Re: PBM design and formulae - a summary
gym@dcs.ed.ac.uk (Graham Matthews)
Tue, 29 Jun 1993 11:55:07 +0000

Referenced By

Re: PBM design and formulae - a summary
desj@ccr-p.ida.org (David desJardins)
Tue, 29 Jun 1993 21:24:09 +0000
Re: PBM design and formulae - a summary
gym@dcs.ed.ac.uk (Graham Matthews)
Wed, 30 Jun 1993 10:33:28 +0000
Re: PBM design and formulae - a summary
desj@ccr-p.ida.org (David desJardins)
Wed, 30 Jun 1993 20:13:49 +0000
Re: PBM design and formulae - a summary
gym@dcs.ed.ac.uk (Graham Matthews)
Tue, 29 Jun 1993 11:55:07 +0000