| From: | Waffelmeisters <evamarie@**********.NET> |
|---|---|
| Subject: | Re: VR 2.0 |
| Date: | Sat, 30 May 1998 04:26:38 -0500 |
>
> On Thu, 28 May 1998, Jeremy "Bolthy" Zimmerman wrote:
>
> > I do believe there's upgrading rules in the book. And purchased copies
> > come with the source code as part of their price. Without the source, it
> > costs about 25% less. I think you just have to subtract one size from the
> > other to determine cost/time to program.
>
> Yeah... these rules seem a little too simple to me. I'd think that
> updgrading a program should take slightly longer. Otherwise, there's no
> reason to write things from scratch, because some Restrict-10 Area DINAB
> targeting program is actually just the result of a slow improvement of
> that Restrict-3 you had five years ago.
>
> Phil
There wasn't any restrict program 5 years ago... but aside from that,
why shouln'ta program be gradually upgraded? The fact that size ~ the
square of rating means high-level upgrades still take a while. Also,
the size of options that are NOT being included should not count- in
fact, I might count them AGAINST the work, if thats the only version you
have, since you need to "remove" those options. Certain optionsmight
then render most of code useless for writting- particulary ones that
affect code size as a "percentage". other versionsFor example, an
Attack with targeting and an Attack with stealth2 are the same size, but
that wouldn't mean theres no "upgrade time"between the two. First you'd
have to "downgrade" to a normal Attack (or use an old Attack to work
from), then upgrade to Attack with stealth. I would say Attack+stealth2
could be upgraded dirrectly to Attack+stealth3, though. In fact, I'd
also say you could "downgrade" a program if you just wanted a smaller
utility. Just "program" the difference in MP's.
This all assumes you have the SOURCE CODE. A "compiled" program can't
be changed, and although theres no mechanic to prevent simple copying,
although I think that is also the intention in VR2.
-Mongoose
