[257 RobotZ]
>All robots need a number and it should be not too many bits when
>communicating.
Agreed. One byte as ID should suffice, which makes 256 robotz...
>Therefore, you can have 256 external robots plus one for the computer itself.
No, 255 external IDs, plus one ID for the computer itself. When it wants
to send data it has to have a means to make the others be able to identify
him.
>You don't need to send the data of the robot that's listening. It knows what
>it sent...
<after a minute of puzzlement>
Ah! I C! Let me try to explain what I think that you mean.
All computers are connected in a ring (Joynet basic principle number 1 :-))
Communication takes place in one direction, lets say from right to left.
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.
Then it can send it's own data block again and the next N-1 blocks recieved
etc, etc...
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!
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...
>> So what? Can't you write two robot-programs? :-)
>Hehe... It will be boring after a while. If you make the possibility to play
>against the computer (not using joynet), you could also spread robot-programs.
When robot-programs are spread you can take the program of another and your
own to play agains each other. No need to have a real 'computer' player.
Or do we have a slight different opinion of 'computer player' and are actually
saying the same?
>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.
That's why leaving the programming language open to the programmer is so
good. Disassembling compiled TurboPascal or MSX-C code is quite hard...
On the other hand, if the source code of another program can help you to
improve your own program, you can get a real evolution of programs...
> [idea!]
>It is possible, of course, but how do you check if a language does not
>cheat?
A language can't cheat. Only the program (sorry for the lecture :-))
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.
> Anyway, when I finish the game, I'll make the communication protocol
>public,
Let's first try to define the _exact_ playing rules. Then it's easier to
define the communication protocol. I'll sleep on it this weekend :-)
> so everybody is free to make his/her own language.
I think you didn't quite understand what I meant: I was talking of _using_
a programming language to program the robot , not specifically _making_ it.
You only define the _playing rules_ and each and everyone can make a program
in any language (C, TP, asm, BASIC, COBOL) that obeys the rules and tries to
win...
Eric
****
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/)
****
