On Wed, 9 Dec 1998 [EMAIL PROTECTED] wrote:
> >Sending the complete map? Not necessary!
>
> No, just the data of the robots. Which raises the question which data
> a robot should have and which are sent to the other robots:
> Public:
> - Position (of course)
> - alive sign (so other robots will know whether a robot is still in play)
What also should be sent is the action performed on sqares (attack and
drop), since the other robots have to react to it. If communication is
possible, I would think it better to give it a maximum length, so the
network doesn't get too slow.
> Private:
> - Energy
>
> Or would it be more fun if all robots would know about each others
> energy level (I see complete hordes of robots turning against the
> weakest :-))
What I would like is having separate energie for:
- shield
- attack
- move
And one main energie type, which can be transferred to (not from) those
types. To make this work, it will be useful that transferred energie
cannot be used in the same turn as it was transferred. Otherwise,
everybody would just have all his/her energie as shield at the end of
every turn, which would make the separation useless.
> >Do you want the program to be the only parameter for the robot, or are there
> >other settings as well? For example, it could be an option to make a robot
> >that receives more damage from attacks, but in return it would move faster.
>
> That hasn't been discussed, yet. But we assumed each robot could only move
> one square (4-neighbourhood) per turn, so an agility/dexterity trade-off
> is not possible. It could however be possible to divide the available power
> between defence (shield, whatever) and attack power.
With energie separation as stated above, this would make it part of the
program. I think it would make the programming too complex if you have to
choose the hardware as well. I think we all agree on it that the language
should be as simple as possible.
> >About the map: is every square (I assume it uses squares, not hexes or
> >something else) accessible? Or are some squares blocked (obstacles)?
>
> Squares are fine :-)
> I'd say that all squares are accessible. What do we do, however with
> dead robots? Are they removed from the field or will they stay as obstacles?
I'd like them to stay, but if anybody has good arguments for removing
them, it's fine with me. I think it would be nice if in a scan, you can't
see if a robot is alive or not.
> >When a robot scans the environment, does it get info like "enemy at (-2,-3),
> >friend at (1,-1)" or does it know which enemies and friends are nearby:
> >"enemy type 1 at (-2,-3), friend type 3 at (1,-1)"?
>
> Not discussed, yet :-)
> I proposed an inaccurate long range scanner, giving information about a certain
> part of the playing field, which only delivers the number of robots, energy
> packets etc. Shevek and I worked up a short range scanner, which gives
> detailed information about a small environment surrounding the robot.
I'd say that with short range scanning (looking) you can see also the
ID-number of the robot and its communication at channel "local".
> Team play has not been discussed at all (apart from mentioning it w.r.t.
> the energy packets), so all other robots are of type enemy :-)
I agree.
> > Maybe a robot can even identify individual enemies and friends, to remember
> >"I damaged that one pretty seriously last time I saw it, so now I'll finish
> >him off".
>
> IMHO that should be left to the robot programmer - the programming language
> for the robots should have the means to do things like that, of course...
This would be possible with the scan mentioned above.
> >When using multiple robots in a team, can they communicate? Cooperation would
> >be much more diverse if communication is allowed. And if they can communicate,
> >are they allowed to send as much info as they want per turn, or only a limited
> >amount?
>
> I think that team play would be very hard if no communication can take
> place between the robots of the same party. But, as already stated, team
> play has not been discussed yet. IMHO team playing makes the whole thing
> very complex, and simplicity should be the thing to strive for. The more
> complex we define the possible behaviour, the complexer our programming
> language will become. That will definitely have an impact on the code size
> of the robot programs _and_ on the code size of the compiler/parser.
There should be a maximum size, if only for the coder of the
robot-language, so he knows the size he must reserve for this purpose.
But how much?
For communication, I suggest the following method:
Every robot can send signals at certain channels:
-local:only readible for robots that can see the robot. Costs no energie
-group:readible for every robot of a certain group (It does not have to be
it's own group) Should cost energie (How much?)
-all:readible for everyone. should cost energie (how much?)
I think it would be good if the robots cannot see who sent the signal, so
a team has to use a code to check if it was somebody from his own team or
not. And of course it would be worth it to break your opponents code.
> >How much work space does a robot get? Just for practical reasons (MSXes don't
> >have megabytes of memory) we need a limit.
Fixing the maximum space implies you are only allowed to make programs in
the original language (so, not in pascal or something). I think this would
be acceptable, since otherwise you could make a winning robot, just
because you put more memory in your computer.
> I would say: make it fit in 32k. That makes it easy to put the robot program
> in e.g. memory pages 1 and 2 ($4000 - $BFFF), have the 'robotz operating
> system' in page 0 an da lot of workspace for it in page 3...
Sounds ok.
> Another thing. How will the process of creating a robot and playing it
> be like? I mean, will we have one program that reads the robot source
> code and execute it immediately (probably after compiling it into memory)
> or do we separate the process of compiling the source code and running
> the compiled robot. (ehm... shorter: compiler+executor or interpreter or
> even a JIT-compiler?)
A compiler would be very hard, I think. What is easier is to write the
source and encode it before it can be executed. This encoding should of
course be extremely hard to decode... which raises the question: how does
the operating system running the robot do it? Using a password is not a
real solution, since then you can decode it if you can play it (but isn't
that always the case?)
> I think it would be fun to have the compiler and executor separated. In that
> way you can create your own robot, and distribute the _compiled_ code, so
> others can test/play with your robot, but not hack it easily...
Not to code easily, eighter...
> I'll try to make some time to give a first indication of the robot machine
> language...
Great. I can't wait to read it.
> Eric (Damn! How can I ever finish my own game when projects
> like this turn up? ;-))
Time is a question of priority (I know, in dutch it sounds much better,
but it's still very true)
Bye,
shevek
****
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/)
****
