Daniel Lepage on 25 Dec 2003 14:51:29 -0000


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

Re: [spoon-discuss] Robot Commands 


On Thursday, December 25, 2003, at 05:17 AM, SkArcher wrote:


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.
Well, that's why the solar panels only produce enough energy to move once per nweek. Perhaps later we can incorporate Weather again, and have 'cloudy days', where everyone has to either do nothing or hope they've got a reactor.
How exactly were you expecting Robots to gather RUs? It doesn't make sense to me that they'd just find them lying around; something should have to happen instead. That's why I liked the idea of having them digging through the Junk - at the very least, they can melt down the Junk they find for RUs.
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. 

Sounds good.


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. 

Sounds like a plan.

--
Wonko

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