| From: | Dave Sherohman <esper@*****.IMA.UMN.EDU> |
|---|---|
| Subject: | Realism in Stripping |
| Date: | Wed, 21 Jul 1993 18:12:24 -0500 |
First up, from Hayden...
>> I think we're delving a bit too much into reality in the attack and defense
>> of strips.
>Good god! See the post I just made. I think we agreed on something.
Guilty as charged. But that's because I'm the sort of person who's bothered
by game elements that have no rational basis. I have a hard time accepting
a program that patches MPCP-specific data into a program without itself
being MPCP-specific - if it can just look up the info somewhere, then why
can't the stripped program do the same thing and thus remain portable?
>> My View: Commercial Programs are already compiled for something just short
>> of the maximum speed.
(This was actually from the Deb Decker, not Hayden.) Compiling to optimize
speed is _not_ the same thing as compiling to optimize size...
>My View: Commercial programs are designed to be most portable.
A Third View (Mine, of course): Computer systems are designed to make the
software portable by using a relatively standardized OS. (Basically taking
the Universal Macintosh Interface idea a bit further.) I strongly prefer the
original explanation of Strip's operation - it finds sections of program code
that are (more-or-less) functionally equivalent to sections of MPCP code and
replaces them with calls to the MPCP's similar code. This is a different
form of code optimization than what seems to be currently discussed, and I
can easily see this being MPCP-specific.
> The reasoning is that the code for both Fuchi and
>Fairlight is in the program. If you have a Fuchi deck, that Fairlight
>code just eats space. STRIPping removes the redundant code.
But if that's all that stripping a program does, then why would the stripped
Fuchi code not be portable to other Fuchis of the same model?
> I think there are rules somewhere
>in VR to deompile a program.
Nope. VR doesn't acknowledge the possibility - VR p.26 (talking about
Upgrading Procedures for the software component of systems) says that,
"Only the original master source code can be used for upgrading."
And in another post from Hayden...
>Hmm, as I've said before, I think we are getting a little to specific
>about this.
Depends on how you look at it. I don't consider this to be nearly as
trivial as "are the graphics generated by the deck or the node", but
DLOH would likely give the same response to both...
>What this accomplishes from a Game Balance{tm} standpoint is that the
>program is HUGE. A rating 10 STRIP is 1000Mp!
a) I don't accept game balance as a reason... b) What difference does
it make how big Strip is? You're not going to be running while you're
online (well, probably not...), so memory constraints (rather than MPCP
rating) become the main limiting factor on highest usable Strip, but have
no other effect.
And, finally, from Nightstalker:
> I see no real need to create a program that
>allows people to reduce the size of their programs.
Personally, I don't like this business of "every Rating X Foo program is
the same size." This is the first proposal I've seen (with the compilers
coming up soon afterwards) which does anything about it. Hmm... Maybe I
can adapt something of the sort for the Ars Magica spell design/lab rules...
>not asking for much, just something better than "I think there should be a
>program that reduces the size of programs. Let's call it strip and who cares
>how the damn thing works."
I care how the damn thing works... (Apparently, I care a little too much...)
I think it's a good idea, I'm just looking for effects that are consistent
with the explanation (or, I suppose, vice versa - though that's almost as bad
as invoking game balance as a reason...).
esper@***.umn.edu
See Ya in Shadows,
Jason J Carter
The Nightstalker
