Re: Olympia - test vs. production version

From: sjc@cs.purdue.EDU (Steve Chapin)

Date: Mon, 18 May 1992 05:46:33 +0000

}} In article <1992May18.052809.4380@beaver.cs.washington.edu> hauck@cs.washington.edu (Scott Hauck) writes:
}}
}} 1.) Olympia is a service done out of the goodness of Skrenta's heart.  I think
}} two systems is an extra burdon on him that isn't necessary

Sniff.  I don't get no respect.  :-)

}} 2.) Part of the fun of Olympia is potificating on how things should ad
}} shouldn't be.  If things migrated from experimental to production, by the
}} time we saw it it would be set in stone, and we'd have a lot less input

I'm sure this is not the intent, and hope it won't be the case.  I
proposed the idea to Rich, because I get the feeling lots of players
are unhappy trying to dance on quicksand.  I felt that we could still
keep as much hacking going on, behind the scenes, and keep the new
stuff flowing in.  I look at it as a pipeline, and the sole intent of
the proposal is to lengthen the latency, and thus allow us to do bug
fixes, and actually announce changes (what a thought :-) before they
hit the streets.

}} 3.) It's not clear this would eliminate the bugs and disappearing skills - at
}} some time experimental changes will have to be merged into the production
}} system, and we'll have the same problems.  Whatever testing Skrenta will do
}} on the experimental version, I bet he's doing now on the production version
}} right after a change.

True.  But it will introduce a time lag, where we can post here and
say, "I've got this neat idea..." and get the ball rolling on
discussion while we're still finishing something else.  And, we can
then announce how something will look the week before it becomes part
of the game, rather than the week after :-)

}} I think the one things that SHOULD be done is give us a bit more warning on
}} changes.

But we can't, if we don't have two different versions!  The day we put
the changes in, you see 'em, unless you let us have two different
versions.  Even with combat, where I said, "It will be unstable.
We're moving from old to new over the course of a couple turns,"
people were not ready for the changed combat system.

In hindsight, I would rather have gathered input (which I did), then
gone off and hacked it (which I did), and then come back and said,
"Ok, this is what it will look like," (which I didn't, because it was
then in the code) and gotten some feedback, while still installing it
in the game.

That gives players some warning and a definite idea how things will
look,  and me more feedback.  Rich could say "as of next week, exits
will look like this..." because he's already got it written and
tested, and knows what it will look like.

Truth be told, I'm somewhat embarrassed over the job I did integrating
the combat changes:  I took too long, and there was a week there where
things were pretty bad, all sorts of half-implemented stuff.  Right
now, it's pretty close to what I want it to look like, and I'm looking
for a couple of last bugs and doing some tuning.  If I had it in that
kind of shape for the first release, I think everyone would be better
served.

sjc@cs.purdue.edu               Steve Chapin           Today's Grammar Lesson:
             Hear, hear! Who's here who knows whose booze this is?

If I don't want it in my back yard, I don't want it.

References

Olympia - test vs. production version
mckinney@cs.utexas.edu (Durwood Y. McKinney)
Mon, 18 May 1992 04:27:36 +0000
Re: Olympia - test vs. production version
hauck@cs.washington.edu (Scott Hauck)
Mon, 18 May 1992 05:28:09 +0000

Referenced By

Olympia - test vs. production version
mckinney@cs.utexas.edu (Durwood Y. McKinney)
Mon, 18 May 1992 04:27:36 +0000
Re: Olympia - test vs. production version
hauck@cs.washington.edu (Scott Hauck)
Mon, 18 May 1992 05:28:09 +0000