SkArcher on 25 Dec 2003 10:20:37 -0000


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [spoon-discuss] Robot Commands

On Wed, 24 Dec 2003 21:32:41 -0500, Daniel Lepage <dpl33@xxxxxxxxxxx> wrote: 



On Wednesday, December 24, 2003, at 07:38 PM, SkArcher wrote:
On Wed, 24 Dec 2003 19:27:14 -0500, Daniel Lepage <dpl33@xxxxxxxxxxx> wrote: 


<SNIP>
you may want to put in a clause here to deal with possible failure of the webform/e-mail address specified in a circumstance that does not merit an SoE
How about, "The Admin may choose to ignore any commands that are sent anywhere other than to the specified webform/address." This allows em to accept ones sent directly to em, if e chooses; I think we can trust Dave to accept them while the specified forms are down. 



Okay


Some Sample Command Descriptions:


I'd request that something like;

GatherEnergy
5 RUs
choose: none
The Robot gains 20 Energy.
This Command must be the only command executed by the Robot this checking period.
I assumed that solar-powered recharging would be automatic; if you wanted to burn RUs for power as well, I expect you'd need some sort of engine.
That might be a better Idea (reactors?) than solar. I'm concerned about things being too easy. In my Experience, limitations make games like this more fun. Necessity _is_ the mother of invention, after all.
I would also say that including an explicit 'limits' entry in the Command description is probably for the best.
What do you mean? You mean, circumstances in which the Command may not be executed?
Yes. As in my example, the statement 'This Command must be the only command executed by the Robot this checking period.' is a specific limitation, not one that is prevented due to circumstances caused by other robots. 


These would be sent as follows, for example:
1. Move N
1. Dig E
2. Move E
2. Move E
2. Dig S
3. SelfRepair
3. Dig S
I had only been thinking of 1 move per checking period, but if you just want to limit movement by energy/RU costs, thats cool
It will, however, make determining interference between robots much more difficult. If you feel 3 moves per nweek are too few, I would suggest 1 move an nday rather than multiple moves at one checking point.
I'd prefer to restrict gamestate changes to the checkpoints as much as possible... we could say that all the first moves happen in precedential order, then the seconds, etc. 
By this I mean:
At some checkpoint, my robot's orders are: Move N, Move N, Dig W
Your robot's are: Move W, Move N, Dig W
bd's robot's are: Dig S
The map looks like this (X is a filled square):

B . . .
X . . .
. . S .
. W . .

Assume I spent more than SkArcher, who spent more than bd.
So the first moves resolve: my move N interrupts SkArcher's move W; at the same time, bd digs south. Then the second moves resolve: I move N, S moves N (heh), bd does nothing. Finally, third moves: My Dig to the W would interrupt bd's Dig if they'd happened concurrently; but since bd's was the first on the list, while mine was third, eir dig already happened, so mine fails, even though I spent more on it. And meanwhile SkArcher digs W to the wrong place. Heh.
Mmmm, I also wanted to restrict the game to checkpoints, but more rigidly than you do. Whatever, prop it, when it goes wrong i'll blame you. 


The above command list would mean:
At the end of the first checking period, do the following in order:
Move to the north.
Dig to the east.
At the end of the 2nd, do these in order:
Move east.
Move east.
Dig south.
At the end of the 3rd, do these in order:
Repair yourself.
Dig south.
If any of these were impossible, it would be skipped - so if the Bot has only 5 energy at the end of the 2nd Checking Period, it wouldn't do anything. Note that if the effects are impossible, the cost is still paid - if something blocks the Bot's motion east at the end of the 2nd checking period, it will still spend 30 energy trying to move east and failing.
Fine. At some point we may want to include rules for pushing, but that can wait. 

Yes, I think it can.



But not for very long.....


--
_______________________________________________ 
spoon-discuss mailing list
spoon-discuss@xxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss