Hi,
>As far as I understood it, the robot game would be turn based. So if things
>get slow, the spectators might get bored, but the gameplay won't be affected.
Right.
>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)
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 :-))
>>Drop is to drop an energie-packet, so smeone else can pick it up.
>>Only useful when playing in teams.
>
>You could use an energy packet as a kind of "lure" to ambush another robot...
Ow, advanced tactics! Tricky :-)
>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.
>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?
>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.
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 :-)
> 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...
>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.
>How much work space does a robot get? Just for practical reasons (MSXes don't
>have megabytes of memory) we need a limit.
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...
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?)
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...
I'll try to make some time to give a first indication of the robot machine
language...
Eric (Damn! How can I ever finish my own game when projects
like this turn up? ;-))
****
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/)
****
