Re: [spoon-discuss] The Grid (with apologies to the scientists and staff of the Beagle2 project)

[Daniel Lepage <dpl33@xxxxxxxxxxx>]

On Thursday, December 25, 2003, at 06:34 PM, SkArcher wrote:

> Ahh yes, the JunkBots. Armoured Robotic monstrostities. Size was more 
> or less meaningless here, but they should each fill a Grid Square. 
> Massive tracks for propulsion over the potential volcanic surface, 
> slate-like sides to deflect the theorised flamestorms. Underneath a 
> protected grinder/scoop arrangement would alow them to slowly strip 
> mine the surface for RUs, while a complicated-looking arrangement of 
> fins and panels was actually a deployable armoured Solar array.
>
> Progress was going to be slow for the first few nweeks, but when on 
> the surface, the Robots were practically unstopable.

Hmm... I'd actually been picturing them as tiny little twisted things, 
like somebody took a lot of scrap components and a welder and just 
threw it together, sort of at random. Slap some wheels on, add some 
sort of camera, a few solar cells and an arm with a drill, or maybe 
just a hammer on the end, and there's your bot. That's why the whole 
'finding upgrades in the junk' thing would have worked - they were 
essentially made of junk anyway.

Maybe we can do that once this gets old, so there'll be all sorts of 
Robotic Monstrosity bits lying about...

> for example, did you know that Grid Objects are all chocolate eclairs?

r1634: A $ENVIRONMENT object, where $ENVIRONMENT is the name of an 
extant environment, is an object which may occupy a location in the 
named environment.

r1635: There exists an Environment called The Grid.

Thus, a Grid Object is an object which may occupy a Location in the 
Grid.

> here is a protoproposal which defines Grid Objects, JunkBots, Parts, 
> Upgrades and Resource Units properly. If there are no objections I 
> will make this prop as is.
>
> create a rule;
>
> {{
> __Grid Objects__
>
> Grid Objects are Game Objects which must occupy a Location in the 
> Environment known as The Grid or an Object which is itself a Grid 
> Object [[so you can put grid Objects into Boxes on the Grid]]. A Grid 
> Object which does not satisfy these conditions is destroyed unless the 
> Grid Objects definition or a rule states an alternative result.
> [[
> note: it's not enough just to say no it isn't. You have to provide an 
> alternative.
> ]]
>
> Only Grid Objects may occupy Locations on The Grid
> }}
>
> [[
> who wrote rule1636, where it reads
> "A Grid Move is a shift from one Square to a consecutive Square of a 
> Grid Object."
> which should be
> "A Grid Move is a shift from one Square to a consecutive Square by a 
> Grid Object."
> as the current version is misleading, sounding like the Grid Object 
> has squares, which are Locations?
> ]]

The phrasing is ambiguous, but the first is closer to the intended 
meaning - a Grid Move is a shift of a Grid Object from one Square to a 
consecutive Square. Objects can be Moved, or they can Move; your 
definition implies that the object itself must cause the Move.

> replace the text of rule 1636 with the following
>
> {{
> A Grid Move is a shift from one Square to a consecutive Square by a 
> Grid Object. Such moves take affect at the end of the Checking Period, 
> in the order in which they were performed.
>
> If an attempted move is illegal, it does not occur.
>
> If a move takes place that causes another move, the caused move takes 
> place immediately after the move that caused it.
> [[
> this is to allow for pushing
> ]]

Isn't this implicit? If some effect causes another, it is assumed to 
happen immediately unless specified otherwise.

> Unless otherwise specified by the rules, no Grid Object may make a 
> Grid Move more than once per Checking Period.
> [[
> Wonko - this is in the current version of the rule, and will prevent 
> multiple moves by a JunkBot per checkpoint - want it removed?
> ]]

That would be good - even if we do decide in favor of a 
one-act-per-checkpoint system, we'll want it to be based on Robot 
actions, not on moves.

> Grid Objects may have Status Attributes. Status Attributes are 
> Attributes which exist only for Grid Objects. Objects that are not 
> Grid Objects may not have Status Attributes. Grid Objects may not have 
> Attributes that are not Status Attributes. Status Attributes may be 
> refered to as Status for ease of reference.
> [[
> Rather than 'The Nuggets Temperature Status Attribute is Hot' you can 
> just say 'The Nuggets Status is Hot' - no need to clarify unless 
> someone queries it.
> ]]

What makes a Status Attribute different from a normal Attribute? i.e., 
why can't we just say "Nuggets may be either Hot or Cold", instead of 
"Each Nugget has a Temperature Status Attribute, which may be either 
Hot or Cold"?

> }}
>
> create a rule;
>
> {{__JunkBots__
>
> JunkBots are Grid Objects.
>
> A. Ownership.
> 1. A JunkBot must be owned by a Player.

I disagree. Players may own JunkBots; but I intend to add other ways 
Junkbots can be controlled (for example, an Admin-owned AvatarBot, and 
perhaps some unstable RabidBots that nobody controls)

> 2. No Player may own more than one JunkBot.
>
> 3. A Player may abandon a JunkBot at any point. A Player who forfeits 
> the game or is garbage collected abandons eir JunkBot as a part of 
> that action. An abandoned JunkBot becomes a Nugget, and becomes of 
> type Hot.

You probably mean 'status hot', not 'type hot'.

> 4. A Player may give eir JunkBot to another Player, providing that 
> Player consents to recieve the JunkBot, does not already have a 
> JunkBot, and is not otherwise prohibited in the rules from owning a 
> JunkBot.

You should specify which Player you mean - the receiver needs to 
consent, not the giver. They already did.

> 5. A Player who does not own a JunkBot, and who has never owned a 
> JunkBot, shall be given a JunkBot if e states 'I request a JunkBot' in 
> a public forum.
> [[
> this gives new players a JunkBot for free, and gives us all one each. 
> In case you hadn't noticed, no-one has any points right now.
> ]]

I am opposed not to the principle, but to the bit about public fora. I 
feel it would be much nicer if the ruleset allowed players to take 
actions, and then we said somewhere that "a player may take any action 
permitted to em by the rules by stating, in a public forum, that e 
takes that action." (as opposed to having many places in the rules 
where it says "a player may take action X by declaring that e does so 
in a Public Forum";)

> 6. A JunkBot may be purchased for 20 points.

The reason I wanted them to cost Bandwidth as well is because I would 
quite like to see bandwidth become a serious part of this game. At the 
moment, the proposals system is only a means towards the end of 
building subgames like the Grid; I'd like to see all sorts of other 
things that can be done with Bandwidth Chits, and ways to compete for 
it or with it.

Also, you should specify that a *new* JunkBot may be purchased. 
Otherwise I can buy yours, or any abandoned one.

> 7. A JunkBot which has been purchased per part 6 of this section of 
> this rule, or which has been given to a player per part 5 of this 
> section of this rule, shall instantly be placed within the Lander, a 
> grid Object at 6,6 on the Grid.

Why not just, "When a new JunkBot is created, it is placed within the 
Lander"? Also, I don't think you should describe the Lander here. If we 
come up with a way to move the Lander, I wouldn't be surprised if 
people forgot about this clause. Then we'd either have two Landers, or 
the Lander would keep getting moved back; but we probably wouldn't 
realize it immediately.

> B. Construction
>
> 1. JunkBots may have Parts. A Part must be installed to have any 
> effect on the JunkBot. A Part which is not installed is considered 
> Cargo. A JunkBots' installed Parts determine what, if any, actions it 
> may take, but do not cause it to take those actions undirected. Each 
> Part has a Size, which may be zero or any real number. A JunkBot may 
> not have Parts with a total Size greater than its Structure installed.
> [[
> If we put damage in, remember to put in a way to determine which parts 
> are affected by this, and how - does the structure damage destroy the 
> Part, or just disable it, etc. For now this is just a utility rule to 
> limit the number of Parts any given JunkBot can have.
> ]]
>  When created JunkBots have 1 Standard Drive Unit, 1 Standard 
> Scavenger Arm, 1 Standard Solar Array, 1 Standard Cargo Bin and 1 
> Standard Manufacturing Unit. All of these Items are already Installed.
>
> 2. JunkBots have a Structure. Each JunkBots structure has an initial 
> value of 5. Structure is a Status Attribute.
> [[
> Structure is effectively Hit Points. I named it something different to 
> allow for the addition of anti-weapon armour after weapons are 
> developed.
> ]]

What happens if a JunkBot's Structure decreases to where its Parts are 
too big? Game precedent suggests that changing the gamestate to an 
illegal state is illegal (which is why saying "A JunkBot may not have 
Parts with a total Size greater than its Structure installed" prohibits 
players from buying more Parts than the Structure permits); by the same 
reasoning, if no method is specified for dealing with a Robot that has 
many parts and just lost structure, it must be illegal to decrease a 
bot's Structure lower than the sum of its Parts.

> 3. JunkBots have a Memory Capacity. Each JunkBot has an initial Memory 
> Capacity of 3. Memory Capacity is a Status Attribute.
> }}
> [[
> so now we have JunkBots, but we still need their parts. first however 
> I want to tie up some easy lose ends.
> ]]
>
> create a rule;
>
> {{
> __The Lander__
>
> The Lander is a Grid Object.
> The Lander is situated at 6,6 on The Grid.
> The Lander may not move. The overrules any rule which says that the 
> Lander moves.

Why can't it?

> JunkBots which attempt to move into the Location 6,6 instead move 
> inside the Lander.
> The Lander has 9999 Capacity. Capacity is a Status Attribute.
> }}
>
> create a rule;
>
> {{
> __Nuggets__
>
> Nuggets are Grid Objects.
> Nuggets have a Status Attribute Temperature. A Nuggets Temperature may 
> be Hot, or it may be Cold. A Nugget must be of one, and only one, of 
> these options. Any rule which states that a Nuggets Temperature ceases 
> to be one of these causes it to become the other.
> A Nugget that becomes Hot, or is created as Hot, remains Hot for an 
> nweek, and then becomes Cold.
> A Nugget may be used as 5 RUs in any situation which requires RUs. If 
> the Nugget would only be partially consumed, all of it is consumed.

Used how? Can I just declare "I use the Nugget at (2,2)"?

> A Nugget is of Size 2. Size is a status Attribute.
>
> }}
>
> create a rule;
>
> {{
> __Resource Units__
>
> Resource Units are Grid Objects.
> Resource Units may refered to as RUs.
> 1 RU is of Size 1. Size is a Status Attribute.
> RUs may be carried as Cargo.
>
> [[
> Basic requirement if we are going to be mining.
> ]]
> }}
>
> {{
> __Cargo__
>
> Grid Items with a Size may be carried as Cargo, unless stated 
> otherwise.
> Cargo must be carried in a Cargo Container.
> Cargo Containers are a Type of Part.
> }}
>
> [[
> okay, now the hard bit, Parts and Upgrades.
> I doing this I have tried to provide for a framework upon which to 
> build, rather than try to provide eveything. What I am trying to do, 
> however, is to force us to specialise and co-operate.
> ]]
>
> create a rule;
>
> {{
> __Parts__
>
> Parts are Grid Objects.
>
> There shall exist the Parts List, which is a Game Document. The Parts 
> List contains an entry for each possible Part. Entries on the Parts 
> List shall be in the following format;
>
> PARTNAME:TYPE:SIZE:LEVEL:DESCRIPTION:ALLOWS:RESTRICTS:COST#(1,2,3...)
>
> 	PARTNAME is the name of the part in question, e.g. Standard Battery 
> Unit, SkArchers high velocity 	Railgun, VSOI Anhilatotron, etc.
>
> 	TYPE is a text Status Attribute. Some Types of Part are restricted in 
> numbers.
> 	Each JunkBot may have only one Part of TYPE Propulsion.
>
> 	SIZE is a numerical Status Attribute. It may be any real number or 
> zero.
>
> 	LEVEL is a numerical Status Attribute. It may be any real number or 
> zero. Players are asked to make 	more complicated/effective Parts have 
> a higher Level.
>
> 	DESCRIPTION is a text Status Attribute describing the Part in question
> [[
> flavour text and room to encourage fiction
> ]]
>
> 	ALLOWS is a text Status Attribute which gives details on how the item 
> may be used. In many cases 	this text will describe ways in which a 
> JunkBot with the item may ignore a certain rule or peform an 	action 
> otherwise not allowed or not described under the current rules. In 
> such cases the text of the 	ALLOWS attribute has the force of rule 
> equivalent to this rule.
> [[
> basically, a part which is in the Parts List is a legal item and the 
> actions it performs for a robot are legal. duh.
> ]]
>
> 	RESTRICTS is a text Status Attribute which gives details on actions 
> which the Part may not perform, 	or which the JunkBot carrying it may 
> not perform, over and above the ordinary rules. In such cases 	the 
> text of the RESTRICTS attribute has the force of rule equivalent to 
> this rule. In cases of 	conflict, the text of a RESTRICTS attribute 
> have a higher power of rule than the text of an ALLOWS 	attribute (as 
> RESTRICTS appears after ALLOWS in the text of this rule), subject to 
> the power of a 	specific over-ride of this general power of over-rule.
> [[
> see r33, r497 and r1302
> ]]
>
> 	COST is a numerical Status Attribute which may exist multiple times 
> for a specific part, and will be 	denoted as COST#1, COST#2, COST#3, 
> etc. COST must include a nonzero real number and a form of Units, 
> 	being a recognised Object Type contained by the JunkBot manufacturing 
> it, or a Status Attribute 	possesed by the JunkBot.
> [[
> the bot has to have the items the Part is made out of to make it.
> ]]
>
>
> Parts can be manufactured by any JunkBot that has a Part Maker which 
> can create Parts of that Level, and enough Items and Resources to pay 
> the cost of that Part.

Maybe I just missed it, but what's a Part Maker?

> Parts may be installed within a JunkBot, providing no rule or 
> subsection of this rule specifically prevents it.
> [[
> See the JunkBot rule, where it is specified that Parts can only be 
> installed with a total Size of up to the JunkBots structure.

What about declaring somewhere that, for example, I can't install the 
same part more than once, or I can't install a part I don't own in my 
Robot?

> Also, I was thinking about having to have the JunkBot Shut Down and 
> have the part installed by another Robot. Thoughts?

I think that might makes a bit *too* dependent on others... encouraging 
cooperation is good, but I don't want to see some poor player wandering 
around weakly because nobody has the time to install stuff on them.

> ]]
>
> If a Part has not been installed within a JunkBot, it is instead 
> treated as Cargo.
>
> }}
>
> add the following to the Parts List;
>
> {{Standard Drive Unit:Propulsion:0:0:The Standard Tracks of a 
> JunkBot:The JunkBot may move 1 square directly forward, or change 
> facing once, per Checking Period:The JunkBot must expend 15 Energy to 
> use this Part:0}}
>
> {{Standard Scavenger Arm:GatheringTool:0:0:The Standard Gathering Tool 
> of a JunkBot:The JunkBot may obtain 1 RU:The JunkBot must expend 5 
> Energy to use this part:0}}
>
> {{Standard Solar Array:Power Generator:0:0:The Standard Power 
> Generator of a JunkBot:The JunkBot may obtain 20 Energy by using this 
> Part:No restrictions:0}}
>
> {{Standard Cargo Bin:Cargo Container:1:0:The Standard Cargo Container 
> of a JunkBot:The JunkBot may hold items in this Item, up to a maximum 
> of Size 1:Multiple Standard Cargo Bins must have seperate cargo, 
> larger cargos cannot be spread across several Standard Cargo Bins:0}}
>
> {{Standard Manufacturing Unit:PartMaker:0:0:The Standard Manufacturing 
> Unit of a JunkBot:The JunkBot may make Parts of Levels 0 and 
> 1:Standard Manufacturing Costs must be paid:0}}

Is Standard Manufacturing Cost defined somewhere? Or is it intended to 
be the COST field of a description?

> [[
> all of the above (apart from the Cargo Bin) are Level 0, Size 0, Cost 
> 0. The Cargo Bin is Size 1 (otherwise there is the potential for 
> infinite - or at least 9999 - storage capacity). The idea here is that 
> these can always be used to get a damaged JunkBot up and running. Not 
> that we have damage, or even any alternative units to replace these 
> with yet, but its a framework.
> ]]
>
>
> Wonko, your programming thing looked fine, see the comments above 
> about Grid movement tho, and I'd like to have facing changes rather 
> than free multi directional motion - it would stop things getting out 
> of hand later the way speeders did if robots actually had to Turn 
> around, and the way I described them (with tracks and all) I sort of 
> like the idea. Robo rally uses this as a concept and it works really 
> well, ask Glotmorf.

I agree that turning would make things more interesting.

> The only real other thing is the idea of having to have upgrades 
> installed by someone else, which would make co-operative work 
> interesting.
>
>
> How many of you have actually read all of that?

I did.

I will attempt to revise some of my earlier protoprops soon; however, I 
will be out of town tomorrow, until the 30th or so, so I may not be 
done for a while.

--
Wonko

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