| From: | Waffelmeisters <evamarie@**********.NET> |
|---|---|
| Subject: | Re: VR2.0 |
| Date: | Sat, 30 May 1998 21:39:24 -0500 |
> Eventually, the program will need an overhaul as the
> additions begin to tax the design of the original program, but it I find
> it quite reasonable that competent deckers should be able to write
> programs which are not utterly from scratch.
>
In any utility, some basic routines will be needed. Thus, upgrading
even a very low rating program into a better oneis fully sensible. The
great MP size diference makes it not so huge a bonus, anyhow.
> I've been working on a rules system to allow this, but I'm wondering what
> people on the list feel should be important considerations.
I posted another response that showed how, in my view, the standard
rules handle this. Basically, options etc not being used must be
REMOVED, first, before upgrading, at the same task rating as programing
them.
> For example,
> when should upgrading a program be a losing proposition as opposed to
> rewriting from scratch?
When you are removing more code than you would eventually be
incorporating into the"upgraded" program, its easier just to start from
scratch.
>Which options should be the most difficult to add?
The ones that change source codesize the most, obviously- they take
lonbger to add.
> For example, transforming a one-shot program into a full utility should be
> very difficult; the one-shot option has a tremendous amount of
> optimization and little tricks which allow it to fit in the smaller memory
> space.
Itis difficult- the source code sizeis +50%. In fact, since
"deproragramminmg" that code will be done at a TN with the programs full
rating,itmightbe easierto start from scratch, working up through a
series of quickly finished lower rating programs.
"Optimization" is POINTLESS to try to remove, since it doubles
sourcecode size.
> Additionally, if it were not difficult, software houses couldn't
> offer one-shot test programs.
You can't do jack with that "sample" program, since it is NOT source
code. In fact, no rul;es aregiven for those "tes programs", but I'd
saythaey can't be put into storage memory, downloaded, or copi4ed in any
wasy- the "vendor" loads them into your active memory, where they must
stay until used. As one shots, attempts to copy them counts as a "use",
and they disapeer.
>Upgrading a program to have an Area option
> should be much more difficult than upgrading the Area to a higher rating.
It is. Upgrading the utility rating adds to rating for size purposes
AND test TN (plus, Prog rating can't exceed "Software" skill).
Upgrading options adds to rating for size ONLY, not programing test TN's
or programing skill limits.
> Thoughts?
Long since thunk of. Given the importance of good utilities and deck
upgrades, it is not a bad idea for a decker to specialize in "matrix
programing" instead of "decking", and the bonus from a math spu and a
task pool REALLY shines here, more so than in straight decking.
Throwing 14+ dice at a programing task is really, really nice... Also,
the equipment needed for a "task bonus" (at least a big MP personal comp
and programing suite, if not time on a host) is definately a worth while
investment. Its nice, if you can, to run MPCP, masking, and sleaze up
to 10, giving you a detection factor of 12 in stealth mode. Deckers
working as programing teams cn do this failry easily, making an all
decker game knda gross.... In fact, utility swapping and team-programing
is one area where regular deckers can walk all over Otaku, who are
essentially expert loners when it comes to "programing". Thier
"channels" are nice, but often lower in rating than a deckers primary
op-utility (though higher than the many he doesn't poor cash / time
into).
-Mongoose
