[MUD-Dev] Containing automation?

[Caliban Tiresias Darklock]

On 01:39 PM 7/25/99 +0100, I personally witnessed Ling jumping up to say:
>
>Lately, I've had a huge leaning towards having an actual R&D cycle.
>
>Player submits design, game time passes whereby the thing is "designed".
>Player gets feedback on feasibility, he then gets to alter the design or
>carry on.  Prototype is built, tested to expose limitations (or not as the
>case may be).  Done.
>
>The main reason was to not overwhelm the player with options on designing
>a vehicle.  Just limit the choice to a few types then let the player
>design more later.  It also turns blueprints into a commodity.

But doesn't this fall prey to Mac syndrome? You pull it out of the box, and
it's easy to work with... but then you get under the hood and it's so
tremendously complex that you may as well not even bother. I would expect
some few people will design blueprints, and that one blueprint will
eventually be viewed as the top end of ship development. This one blueprint
will be the goal of every player, they'll all buy one, and in the end you
may as well not have had ship design in the first place. 

This is sort of like what happens with computer software. Lots of people
make word processors, but the general consensus is that MS Word is the one
to use, so only MS Word does any significant business. Compare office
suites, development environments, graphics programs: on a Windows PC, these
are virtually synonymous with MS Office, MS Visual Studio, and -- to add in
a non-Microsoft product -- Adobe Photoshop. Even though there may very well
be better products available depending on your needs, doesn't the
complexity of finding such products pretty much mandate picking the one
everyone else uses? 

Okay, player-owned ships don't have compatibility issues. ;)

>On Sun, 25 Jul 1999, Caliban Tiresias Darklock wrote:
>
>> The real key to this plan is that any and all of those forty devices can be
>> removed or replaced at any given time. You may, for example, go out
>> exploring and need a vast number of unusual sensors on your ship. Since you
>> don't need them all the time, when you decide to go into sweep-and-clear
>> mode and run around killing everything, you can sell or discard the sensors
>> you don't use often and replace them with weapons. When you log off for the
>> evening, you can discard some of your weaponry and replace it with ship
>> defenses in case of ambush. 
>
>I've gone for the one drone = one function model where a ship would hold a
>zillion drones to do the work.  Kind of similar with different fluff
>around the edges.
>
>What ever happened to the Star Trek mentality of "recalibrating" the
>sensors? :)

I really don't think any of us want that level of realism. Let's say there
are four wormholes in the current sector and their destinations. There is
also a recently-closed wormhole to a fifth sector, and a sixth wormhole of
different properties. UU handles this with three different sensors -- your
basic sensor only sees the four obvious wormholes. A specialty device is
used to see each of the other wormholes. Under the Star Trek recalibration
concept, you would need to scan for wormholes; then filter for trace
wormhole energy signatures by setting a bandpass filter on your sensor
report; and finally redefine the sensors' characteristics of wormholes to
detect the sixth wormhole. 

Now, I don't know about you, but I don't want to define a physics engine
that complex, and as a player I wouldn't want to interact with one. Sure,
it has possibilities, and it's nifty -- but it's just not FUN. Imagine the
instructions: "The signature of a wormhole normally fluctuates between 45
and 65 GHz at no greater than 20 cycles per second. When a wormhole is
recently closed, the frequency of the residual energy is still in this
range, but increases to a magnitude of 120 to 150 cycles per second, making
it too unstable for most drives unless you have a proper harmonic resonator
which can be calibrated to synchronise your ship's vibration to the
residual wormhole energy. Certain wormholes can be found at higher
frequencies, specifically the 900 to 1300 GHz range. All wormhole
signatures are subject to interference from outside sources and cosmic
phenomena. The destination of a wormhole is determined by the fundamental
third harmonic of its base frequency applied to the following formula..."

My game is ALREADY too complex. This sort of thing is nice to write out,
and makes for good atmosphere or background -- but it's just not acceptable
as instructions.

>> We've discussed a change in which we would split the available devices into
>> "hardware" and "software" devices, with some devices needing both hardware
>> and software, but I'm holding off on this concept for the moment because it
>> may be too complex for people to understand.
>
>How about all devices are hardware things but can be augmented with the
>addition of software.  Or maybe have software that uses devices in novel
>ways...

The recalibration idea actually led to this thought, since it seems
reasonably obvious that a great number of sensors are really just software.
The bandpass filter example above, for example; obviously there's a little
more than that involved, for various reasons. But you should be able to
just stick a card in your ship's computer and have it figure out how to
report the trace wormhole energy *as* trace wormhole energy. It's not that
you can't see it, after all, the computer just doesn't know what it is.
While a laser battery or missile platform is obviously hardware, the
targeting of such a device is software. While it seems like a good idea in
theory, it may just be too much for most players to grasp.

Likewise, to many players it may seem intuitive that if you can *buy*
software, you can *write* software. Unfortunately, for every player like
us, there will be dozens who are unwilling or unable to write out complex
scripting functions to automate their ship. This also leads to the
possibility of people thinking so far outside the box that they destroy the
balance of the game; it creates so many thorny issues, I just don't really
want to open that can of worms.

-----
| Caliban Tiresias Darklock            caliban at darklock.com 
| Darklock Communications          http://www.darklock.com/ 
| U L T I M A T E   U N I V E R S E   I S   N O T   D E A D 
| 774577496C6C6E457645727355626D4974H       -=CABAL::3146=- 


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev