Daniel Lepage on 7 Oct 2003 18:59:57 -0000

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

Re: [spoon-discuss] Hey, Rocky! Watch me pull a gnome out of my hat!

On Monday, October 6, 2003, at 11:47 PM, Baron von Skippy wrote:

So if you can mix two basic gnomes to get one yoyo gnome, and two yoyo
gnomes to get three basic gnomes, then if basic gnomes are stage n,
yoyo gnomes are stage n+1, and basic gnomes are stage n=n+2?

-If you did it the other way, basic gnomes would be stage n, yoyos
stage 2n, and basics stage n=4n. Here's a thought: Don't make that
combination. Besides, Basics will be defined to be stage n in the
rule, so your evil plan is foiled again.-

Then the rule will contradict itself, saying Basic Gnomes are both n
and n+2. I'm not speaking in favor of the other scheme either; I'm
saying find a new scheme, preferably one that works.

-And I'm saying don't create cyclic recipies. You can make bread out of flour, water, and yeast. Can you then combine two loaves to get the ingredients back? No. Similarly, you shouldn't be able to merge Gnomes backwards. If you'd like me to write that into the rule, I'd be happy to. I just figured it was more or less common sense.-

Common sense? Since when has that had any force?

I'd prefer a rule that won't break when somebody tries something out of the ordinary; at the very least, say that in the event of such feedback, all gnomes are treated like stage 1 gnomes, or something; otherwise, when somebody makes a loop by accident, you'll go out of business, since the Production cost of all gnomes will be infinite. (or perhaps simply not a number; either way you can't sell them without curious nonquantities of Production points)

And it's worth noting that the old system had cyclic recipes, albeit less obvious ones: "Three Basic Gnomes makes a Gnome of a random type." [[r441/13, from nweek 40]] That combo alone destroys the stage system, since three Basic Gnomes could make another Basic Gnome, so Basic Gnomes must be one stage higher than themselves.

Since every new gnome type will have to be proposed anyway, why not just let the proponent decide what it's stage is, using the merging rule as a guideline?


Version: 3.1
GU/O d-(++)(?) s+:+ a--->+++ C++>++++>$ UB+>++++ P--@ L+>+++ E>++ W++(+++) N+(++) o?>++++ K? w------- O? M++ V- PS@ PE-@ Y-- PGP- t+ 5 X R+ tv--@ b+++@ DI++++ D G++ e*>++++ !h r++ y?

spoon-discuss mailing list