I'm not sure what plocking cloakers has to do with actual clue. That
intangible "clue" is what is hard to code. Coding bots to take planets as
well as humans do, making team plays to accomplish their goals, and so on
would be quite difficult in my opinion. Not to mention, the difficulty of
figuring out exactly what the other team is up to.
Winning the game takes a whole lot more than creating a bunch of robots that
may be tactically superior to the other team. I think Netrek is a much more
complex game than many people realize (especially those who haven't played
higher level clue games). Someone compared it to computers playing chess in
a previous post. While I don't know much about chess past the basic rules,
it's basically a very simple game with a small, fixed number of variables
(with a very, very large number of permutations of these variables of
course, which is what makes it a complex and interesting game). Netrek has
far, far more variables at work in determining exactly what's going on, and
exactly what course of action to take.
On Wed, 5 Dec 2001, Mark Mielke wrote:
> On Wed, Dec 05, 2001 at 04:55:04PM -0800, Tom Holub wrote:
> > This shows a lack of understanding of netrek dynamics. First of all,
> > phaserlocking isn't that hard, and humans do it better than computers,
> > because humans do fuzzy things better than computers. If you feed a
> > computer bad data (as the netrek server does with cloakers), it will
> > take an enormous amount of programming effort to make it perform as
> > well as a human would.
>
> Just to show you that I'm not pulling shit out of my ass.
>
> Consider the 'bad data' sent to the client:
>
> #ifdef AS_CLOAK
> if (pl->p_ship.s_type == ASSAULT) {
> cpl->x=htonl(pl->p_x+(random() % 3000)-1500);
> cpl->y=htonl(pl->p_y+(random() % 3000)-1500);
> } else
> #endif
> {
> cpl->x=htonl(pl->p_x+(random() % 2000)-1000);
> cpl->y=htonl(pl->p_y+(random() % 2000)-1000);
> }
>
> Forget the AS_CLOAK thing for a second. The position is reported as
> being up to 1000 units off on both the X and Y axis. The speed is
> reported as 15 (or something else that is effectively useless). The
> direction is left to be whatever it was before (i.e. no-op updates).
>
> Pretty 'inaccurate', eh?
>
> Now, picture three clients all on the same screen. All three clients
> are robots that talk to each other using some other mechanism than
> smessage(). If three clients are each getting a sensor reading of 'up
> to 1000 units off on both the X and Y axis, but not more than that',
> they can average these co-ordinates together to get a significantly
> more accurate reading. How accurate? Well, the worst possibly
> situation is that they are all off by exactly sqrt(100000 + 100000),
> or around 1414.2 units. What is the chance of this happening? Well,
> about 1 in 10**18.
>
> What is the *probable* accuracy? This depends greatly on the random
> number generator being used by ntserv, and how well distributed the
> numbers are.
>
> The latest code released from this list defines ZAPPLAYERDIST to be
> 390. Consider only one axis for a second, as the result of this
> probability would only need to be squared to determine the probability
> in two dimensions.
>
> How many sets of 3 numbers are possible, given an integer space of
> -1000...999? The answer is, of course, 2000**3, or 8 x 10**9.
>
> How many sets of 3 numbers, in the integer space of -1000...999 add up
> to a sum between -390 and 390? I'm feeling a little lazy, so:
>
> (Yes, I divided the units by 10 to make it execute faster...)
> $ perl -e 'for $a (-100 .. 99) {
> for $b (-100 .. 99) {
> for $c (-100 .. 99) {
> $z = $a + $b + $c;
> $z = -$z if $z < 0;
> $i++ if $z < 39;
> }
> }
> }
> print "i = $i\n";
> '
> i = 2271808
>
> Because it was divided by 10 three times, we need to multiply it by 10 three
> times to come close: 2 x 10**9 (I even rounded down)
>
> 2 x 10**9
> --------- = 1/4
> 8 x 10**9
>
> On two axis', this is 1/16. Normally, on two axis', there is only 1/25.
>
> In summary of the above, with the normal 'inaccurate' information,
> there is a 1 in 25 (4.00%) chance that a cloaked ship will be revealed
> by a phaser beam directed at the location actually sent by the server
> from any direction, at the very longest range that the ship can fire a
> phaser at. If three clients are receiving information, this can be
> increased in our favour to 1 in 16 (6.25%). This may not seem like
> much, but if you look carefully, this is a 56% increase in accuracy
> under extreme conditions.
>
> The 'extreme conditions' are, if we are exactly one phaser length away
> from his actual position (in any direction), the percentage represents
> the chance that we will be able to reveal him by only averaging the
> co-ordinates that are available to us, and firing at that point. At
> exactly one phaser length, the damage will be 0. (This is assuming
> that we do not possess knowledge that he is exactly one phaser length
> away... such knowledge would greatly increase our odds... :-) )
>
> Under more realistic situations, he will often not be exactly one phaser
> length away. He may be more, or he may be less.
>
> How to narrow it down? Well, if you have one set of co-ordinates, the
> greatest probability to hit him on the first shot is achieved if we
> can be certain that he is not on our 'other side'. As the server will
> report him +/-1000 units, the server must report him as at least
> 2000-390-390 units away in order for us to maintain the greatest odds
> of hitting him. (He is then at least -389..1220 units from us, all
> within the range of our phaser)
>
> If three clients receive three different sets of co-ordinates, we can
> reduce the 2000-390-390 units for the closest reported set of
> co-ordinates by the difference between the furthest reported set of
> co-ordinates. I.e. if one client reports him at a distance of 1000,
> while another clients reports him at 1500, we can deduce that the
> closest he could possibly be is 500 units, and the furthest he could
> be is 2000 units.
>
> Not coincidentally, the greater the range of co-ordinates sent to us
> by the server, the more accurate our readings are. As an extreme
> example, if one client is told that he is within 1000 units of a
> point, and another client is told that he is within 3000 units of a
> point, we can be 100% certain that he is exactly 2000 units from the
> point. For my numbers, I am assuming an even distribution, and not
> taking these additional numbers into account.
>
> K... I'm getting tired, so I'm going to stop here. Suffice it to say
> that quite a bit of information can be transferred to offer a fairly
> large 'edge' in many situations. Exploitable patterns or not, the
> computer has a decisive advantage in terms of reflex, calculation, and
> organization. If it is programmed correctly, I see no reason why it
> shouldn't be able to beat the best INL team at least some of the time.
>
> I'm not saying it wouldn't take a lot of work. I'm saying that I can
> inject my experience, and the experience of other players into it, add
> a few lightning reflexes, split second team work organization that is
> able to abruptly adjust such that the entire robot team changes to a
> new tactic at the exact same instant if necessary, collective
> information processing that approximates what some might consider
> 'cheating', etc.
>
> If we actually did this, I don't think it would be too much blasphemy
> to label the team 'The Borg'. One mind and all that. It would be
> really cool to use custom graphics that were a little cold and
> calculating for the COW client to offer an atmosphere of
> omnipotence. "Resistance is futile. Prepare to be assimilated into the
> collective."
>
> Tom: Do you see the potential, even if you don't believe it would ever
> amount to anything in your life time? And even if exploits were found,
> watching the game and then make mild adjustments, or re-writing
> sections of code to eliminate the exploit can be a very effective
> method of "AI" evolution. If situations exist with several variables,
> the robot teams could be set against each other with different
> settings, and the top 50 performing settings could be randomly chosen,
> or switched between during actual combat with human players. They
> could be weighted according to success against different teams as a
> method of emulating 'learning'. If the team begins to lose, it would
> choose one of the other 50 pre-canned settings. It might be desirable
> to weight the settings such that the robot team might be able to judge
> one settings as perhaps offering a greater chance of success against
> another setting upon observation of the strategies used by the other
> team.
>
> mark
>
> --
> mark at mielke.cc/markm at ncf.ca/markm at nortelnetworks.com __________________________
> . . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
> |\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
> | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
>
> One ring to rule them all, one ring to find them, one ring to bring them all
> and in the darkness bind them...
>
> http://mark.mielke.cc/
>
> _______________________________________________
> vanilla-list mailing list
> vanilla-list at us.netrek.org
> https://mailman.real-time.com/mailman/listinfo/vanilla-list
>