SkArcher on 25 Dec 2003 23:37:43 -0000


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

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


On Tue, 23 Dec 2003 19:26:34 -0500, Daniel Lepage <dpl33@xxxxxxxxxxx> wrote:



Some Fic, inspired by the Beagle 2 probe situation, followed by a LOT of rules


***************


The Players waited. With the recent emergency over, they all found themselves returned close to the Origin, and they only differed from one anothers position in one dimension. Respect. Anything McGee, Sagitta, Teucer, The Pusher Robot and Wild Card had almost ceased to be. With no respect they returned to the origin and were surounded by, indeed at times almost seemed to merge with, the Stars.

Since the Grid had been destroyed they had been like this. Even conceptual games of Political Go had only held their interest so long before they had worked out how to manipulate the system to the best effect. Now none of it meant anything. The grand reset had come around, all points and everything else had been reset. The Game was as close to null as it had been since Rob joined.

Now they were waiting to see if the Plan had worked. It was, necessarily, limited. Long debate had come up with the Plan. It was risky, but the Players were prepared for the worst. After all, no matter how bad it had been, it couldn't be as bad as it had been just before the SHIVAs impacted, could it?

Could it?

A lot of the Players were covertly glancing at Wonko. Occasionally one could hear a mutter of 'p1584' from one player, or another. The muttering might have been louder if one of their number had not departed, seemingly out of neglect, shortly after the original grids' destruction. If one glanced down, into the origin, a dimmer entity could just be made out among the Stars and the players gathered there.

A Lost Soul. In a spacesuit.



"What happens if there is no signal?"

It was impossible to identify which player had spoken, in this place, if this was a place. Things like distinct physical presence had been another casualty of the Grid, albeit probably an unintended one. Only the voice of the Admin was still the same, and even e no longer had the avatar to inhabit. Exactly where the Admin was (or, possibly, where the Admin was not), was a matter of some debate.

"If there is no signal, it could mean the lander has run out of power. If that has happened, we will have to wait for them to recharge." It was pretty much guaranteed that was Wonko. Wonko had destroyed the Grid, and now Wonko was taking them back to it.

Or not.

Without a physical presence on the Grid the Players were going to have to act by proxy. Communication delay through the Wild Regions that was once encompassed by the old Grid made direct control impossible. The best they could do was to issue instructions to their proxies in advance and hope nothing unforseen happened, but after all that shouldn't be a problem, should it. After all what could there possibly be on the Grid that could affect a players actions.

Apart from another Player of course. But Players tended not to discuss things like that. Their Proxies were designed for the job in hand, and could modify themselves, given enough time and materials retrieved from the expected conditions, to handle almost anything. Textbook theory on how to colonise inhospitable territory. Their JunkBots were built for this, on what budget they had.

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.

Once they got there.

If they got there.


**********************


right, some things need some good definitions

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

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?
]]


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
]]

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?
]]

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.
]]
}}

create a rule;

{{__JunkBots__

JunkBots are Grid Objects.

A. Ownership.
1. A JunkBot must be owned by a Player.

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.

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.

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.
]]

6. A JunkBot may be purchased for 20 points.

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.


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.
]]

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. 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.
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.

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.

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

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}}

[[
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.

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?


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