At 02:41 PM 12/04/98 +0000, you wrote:
>At the start, some fuzzywuzzy takes place to determine the size of the
>ring - lets say N. Then each computer sends its own data block (to left),
>reads N data blocks, (from right) and sends them all (to left) except for
>the last one which is the data block sent by its left neighbour.
If you program it like that, computers don't even need an ID. They only
need to know the number (N) of computers in the ring.
>In contrast to my idea, where each computer gets a globally known fixed ID,
>you work with 'relative' id's in this method and then you can connect upto
>257 comps. Clever!
It's a nice from a theoretical point of view. But in practice it's more
efficient to add another bit in the transmission, doubling the number of
possible computers.
>Anyway, I think that a competition of 256 or 257 robots will be very close
>to impossible to play. You'd have to have a *huge* playing field to make
>it a bit interesting, which has to be updated and kept consistent over all
>connected computers...
There is a simple way of doing that: make the gameplay deterministic. This
means that there is never a choice with a random factor in it. So if all
computers start with the same field and process the same movements, their
fields will always be consistent.
You may say "no random factors will make a game boring, because two
programs will always play the same battle". But remember that random
numbers in computers are not really random. Usually sequences are used that
look like random numbers. Such sequences are initialised with a "random
seed". That seed is chosen using some more-or-less random properties (for
example, system time).
This means that is the same random seed is distributed to all computers
running the robot wars program, they all play the same game. But if the
game is started again, the game they will play a new game.
>>It might even be possible to encode it, so that you can't read the source to
>>see how to beat it, but that would be quite hard.
If the algorithm is somewhat complicated, just looking at the source code
won't tell you how to beat it.
>That's why leaving the programming language open to the programmer is so
>good. Disassembling compiled TurboPascal or MSX-C code is quite hard...
How do we prevent programs in such a language from cheating? It would be
quite simple for a program to inspect the entire map, to it can look beyond
its sensor range.
Also, a specific robot programming language may be easier for beginning
programmers. Not everyone knows how to code Pascal or C.
Yet another advantage would be that the robot wars program can be made for
other systems as MSX as well. Maybe you disagree about this being an
advantage, but I'd like to see for example a Java version that can be
played over the web.
>To your Q: You can't if you don't use a special purpose robot programming
>language. But with a well defined set of playing rules you can limit the
>possibility of cheating.
A well defined set of rules only makes sure people don't cheat legally. If
they intend to break the rules, it doesn't matter how well defined those
rules are.
The advantage you named of using a general purpose language is at the same
time a disadvantage: it's hard to disassemble, so you can't check easily if
a program cheats or not.
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
